Re: Framebuffer port of GTK/GDK !!
- From: Paolo Molaro <lupus lettere unipd it>
- To: gtk-devel-list redhat com
- Subject: Re: Framebuffer port of GTK/GDK !!
- Date: Thu, 23 Mar 2000 18:50:43 +0100
On 03/23/00 Owen Taylor wrote:
> MicroWindows/Nano-X is a much more active project. But, I was not
> particularly impressed with the code, the amount of documentation, or
> the APIs when I looked at a few weeks ago. It struck me as an attempt
> to write a windowing system done by people who weren't all that
> familiar with windowing systems. It inherits many of the limitations
> and bad parts of the X design, without necessarily inheriting all the
> good parts.
> (Caveat: perhaps the lack of documentation and the ugly header
> files have prejudiced me against the system.)
There are two different issues: the basic library and the two
windowing libraries (microwin and nano-X).
While nano-X may not be the best design, it can be easily changed,
there's no need to comply with an X spec or something.
I'm sure the maintainers won't have any problems with us adding
features. If you have specific issues, please explain them in detail.
Maybe the windows-alike windowing library could be a better choice
for the porting, but I know nothing about win32, so I'll let others
try that route:-)
> On the simplest level, it looks hard to do a full GTK+-1.3 port to
> Nano-GUI since it has the X 16-bit coordinate limitations, and doesn't
> have the features of X that GTK+-1.3 uses to work around those
I don't think the 16-bit limitation is a real problem for the nano-X
port, since it's supposed to be used in embedded devices: there are
already bigger problems there.
> So, I guess I don't think that either of these existing systems really
> is the right way to go. The best thing to do might be to go from
> scratch assuming just a simple frame-buffer (you could test against
> fbdev on linux.) I think that Troll did something like that for
Using the low-level microwindows library would be a good choice here.
> - How small?
Less then 8 megs memory is the main target, but it can be useful also
for bigger machines (over 16 MB it would be better to use an X
server anyway, I think). Maybe using the alpha-channels capabilities
of microwindows could attract also more people.
> - Why is X eating too much memory? (Simply discarding it a-priori,
> is a stupid move. There is a LOT of really good work done by
> smart people in X.)
The X footprint is going to shrink, but still it is too much for
some applications (< 4 MB ram).
> - Is hardware acceleration needed?
Would be nice to have, but it's not a requirement.
> - What level of security / protection is needed?
nano-X uses unix sockets or shared memory.
> - What features beyond what X provides are wanted / necessary?
microwindows provides for alpha support, rotated text: it needs
to be discussed how these features could be exported in the
Paolo Molaro, Open Source Developer, Linuxcare, Inc.
+39.049.8043420 tel, +39.049.8043412 fax
Linuxcare. Support for the revolution.
] [Thread Prev