Microwindows and GTK+

["Greg Haerr" <greg censoft com>]

Hi guys,
    I was curious about how the GTK on framebuffer debate was
going, so I subscribed the list and read through the last few weeks'
worth of interesting conversations in the archive.

A few messages brought up my desire to comment:

[Derrek wrote]

        I will contact the Microwindows maintainer to ask him if
distributing Microwindows under the LGPL is an option; that would allow us
to distribute Microwindows with GDK, as part of the GDK library--and
hence, we could effectively claim Linux framebuffer support (instead of
claiming Microwindows support, which happens to run on the Linux
framebuffer).
[snip]

The MPL+GPL license for Microwindows was created to allow wide usage
of Microwindows without just having it completely free.  I'm very open to adding
LGPL distribution, but I'm not a lawyer, and don't know the implications.
Personally,
I think distributing Microwindows with GDK is a great idea.

On the "positioning" side of things, I agree with earlier posts that it's not
good
to allow QT to build a proprietary framebuffer based widget set and ride ahead
in the fast-emerging embedded systems market without GTK+ "competition".
Microwindows is totally open source and will remain that way.  I've been working
very hard trying to build a product that could become the standard graphics
"server"
for Linux framebuffer.  That's why the original design allowed for the two most
popular
APIs - X-like and Win32-like.

Also, I like the idea of GTK+ being able to claim framebuffer support, rather
than
just Microwindows support.  (The Microwindows support will become more
meaningful,
however, as everyone realizes just how many platforms it enables the widget set
to run on)

Some other comments:  it was mentioned that there's an issue with the 16 vs
32-bit
coordinate system that GTK and then X relies on.  Remember that issue that Owen
mentioned (I agree with the name polution issue):

    typedef COORD GR_COORD;

Microwindows can be compiled up for 16 or 32 bit coordinates.  I'm going
to clean the namespace issues up, but the architecture is such that the APIs
inherit up various aspects of the engine, the size of the coordinates being one
of them.

Finally, I think a Microwindows/GTK+ partnership would be a good one: as you
know,
there's many, many details in building a modern day graphics system.  The split
between
GTK+ concentrating on widgets, and Microwindows handling the framebuffers,
differing
hardware screen drivers, mice, clipping and very low level drawing is a good
one.

So, whether Microwindows is included in GDK or not is merely a matter of
convenience.
You'll always want a clean API between GDK and the windowing system, IMHO.

Regards,

Greg Haerr
Maintainer, The Microwindows Project
http://microwindows.org