Re: Framebuffer port of GTK/GDK !!

[Paolo Molaro <lupus lettere unipd it>]

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
> limitations.

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
> Qt/Embedded.

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
gdk interface.

lupus

-- 
Paolo Molaro, Open Source Developer, Linuxcare, Inc.
+39.049.8043420 tel, +39.049.8043412 fax
lupus@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.