Microwindows and GTK+

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

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.
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
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
for Linux framebuffer.  That's why the original design allowed for the two most
APIs - X-like and Win32-like.

Also, I like the idea of GTK+ being able to claim framebuffer support, rather
just Microwindows support.  (The Microwindows support will become more
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
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
there's many, many details in building a modern day graphics system.  The split
GTK+ concentrating on widgets, and Microwindows handling the framebuffers,
hardware screen drivers, mice, clipping and very low level drawing is a good

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


Greg Haerr
Maintainer, The Microwindows Project

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]