Re: Framebuffer port of GTK/GDK !!

[Owen Taylor <otaylor redhat com>]

"Shawn T . Amundson" <amundson@eventloop.com> writes:

> On Wed, Mar 22, 2000 at 08:09:02PM -0600, Raja R Harinath wrote:
> > > --------------------------------------------------------------
> > > What is Nano-X?
> > > 
> > > Nano-X is the X-like API that Microwindows supports.  It is based on David
> > > Bell's mini-X server API, and includes X-like primitives for low-level
> > > window and graphics operations.  Window management is not included, and
> > > the window look and feel must be created through a widget set or directly
> > > by the applications programmer.  Currently, there are a number of people
> > > working on widget sets for Nano-X.  There is some discussion about
> > > converting the Nano-X API to be X Window System compatible.
> > > --------------------------------------------------------------
> > 
> > I am confused.  I was talking about DinX (dinx.sourceforge.net).  This
> > FAQ entry talks about Nano-X.  I don't think they are the same
> > project, though DinX was last updated in December.  
> > 
> > If this is a continuation of a different conversation thread about
> > Nano-X, that would explain it.  I don't however know the licensing
> > situation of Nano-X, so I can't comment on your suggestion.
> > 
> > - Hari
> 
> I found it confusing as well. ;-) However, similar licensing applies 
> to Microwindows as well.

The licensing on DinX does not seem very relevant since its API is
tiny and the protocol fixed at the device-interface level.  If there
are client side libraries at all, it would be easy to duplicate them
under whatever license you wanted.

DinX, however, doesn't seem to be very active, and I'm not sure
that it's general approach of putting a fair bit of functionality in
the kernel is going to sit well with the kernel people; it also
restricts portability to anything but Linux. (And there are some
fundemental problems with command/event-queue overflow with this
model.)

The approach that DinX takes of only managing top level windows and
leaving everything else up to the client is not a necessarily a bad
one; it would actually be quite easy to adapt GTK+-1.3 to this model,
since the X layer for GTK+-1.3 is duplicating a lot of the things
that the X server is doing in order to work around limitations
in X.

One thing that's a little funny about DinX is that the _only_ way
of drawing to the screen is to copy-area or fill-area. There are
no primitives such as lines, and there is no direct access to
the frame buffer. If you don't mind leaving double-buffering on
(the default way that GTK+-1.3 works, but perhaps not suitable
for embedded systems) then this isn't a problem. 

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

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.

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.

If you want a full multi-client windowing system, then you have
to answer some basic questions first:

 - How small?

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

 - Is hardware acceleration needed?

 - What level of security / protection is needed?

 - What features beyond what X provides are wanted / necessary?

I don't think that this questions were satisfactorily answered
by either the Nano-GUI or DinX people, though DinX, as a simpler,
cleaner system, has less of a problem in this regard.

Regards,
                                        Owen