Re: Framebuffer port of GTK/GDK !!

[Owen Taylor <otaylor redhat com>]

Paolo Molaro <lupus@lettere.unipd.it> writes:

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

I guess the biggest problem I'm having right now is that there are
effectively no docs, so I don't really know what the interfaces are
for the basic library and for nano-X, and I have to try and figure out
what is public and what is not in the header files.

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

An attempt is appended below. I know that it really annoys me when
people attack the GTK+ API without giving specifics, so I've spent
a bit of time on it.

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

I looked at that earlier, and it looked pretty similar in overall
feature-set and the difficulties you would encounter.

Regards,
                                        Owen


NanoGUI critique:
================

* Name confusion. MicroWindows, NanoGUI, NanoX, etc. 

  It's very hard to keep track of what is what. You won't get
  people to write to an API unless you can present a clear,
  unified picture.

  In fact, I doubt the double-API system that MicroWindows has now is
  a good idea at all. They should just pick one or the other, having
  two is just inviting confusion.


* Lack of documentation, and an apparent lack of principles for
  how things should be designed. We are extensively haunted
  in GTK+ now by some of the careless design decisions that were
  was made early on. It's even more crucial for a windowing
  system.

  Where are the API calls documented? Which calls are part of the
  API and what is internals? What are the semantics of the
  drawing calls? (X typically specifies which _pixels_ will
  be drawn, and when that is not defined, clearly states.)

  (The Architecture document on microwindows.censoft.com is something
  but falls short of careful documentation of the interfaces.)


* API ugliness

I actually consider having "nice" API's to be pretty crucial.
This is one of the things that has really helped GTK+ and GLib -
nice "pretty" APIs. The Micro/Nano* APIs fail on this regards.

 - There is extensive namespace pollution. (A failing also 
   of Xlib) Use a namespace prefix and stick to it

  typedef COORD 		GR_COORD;	/* coordinate value */

   (Actually, the failing here is at the device level, not 
   the library API level, but there is plenty of pollution from the
   included header files)

 - Enumerations should be done as enumerations, not #defines, 
   so that debuggers have access to the information.

#define	GR_MODE_XOR	((GR_MODE)MODE_XOR)	/* draw pixels using XOR */
#define	GR_MODE_OR	((GR_MODE)MODE_OR)	/* draw pixels using OR */
#define	GR_MODE_AND	((GR_MODE)MODE_AND)	/* draw pixels using AND */
#define	GR_MAX_MODE	((GR_MODE)MODE_AND)	/* maximum legal mode */

 - All caps should be reserved for macros and symbol values.

   This is standard for GNU code, X, the Linux Kernel, almost any
   C++ program, etc.

  /* Event for a mouse button pressed down or released. */
typedef struct {
  [...]
} GR_EVENT_BUTTON;

* The nano-X API, which is supposed to be "X-ish" is gratuitously 
  incompatible in many places. eg:

 void		GrSetCursor(GR_WINDOW_ID wid, GR_SIZE width, GR_SIZE height,
			GR_COORD hotx, GR_COORD hoty, GR_COLOR foreground,
			GR_COLOR background, GR_BITMAP *fbbitmap,
			GR_BITMAP *bgbitmap);

   The X API has a bitmap and mask, not fg and bg bitmaps

* Parts of the API are perhaps a little random. For instance:

 void		GrBMP(GR_DRAW_ID id, GR_GC_ID gc, GR_COORD x, GR_COORD y, GR_SIZE width,
			GR_SIZE height,char* filename);
void		GrJPEG(GR_DRAW_ID id, GR_GC_ID gc, GR_COORD x, GR_COORD y, GR_SIZE width,
			GR_SIZE height, BOOL fast_grayscale, char* filename);

  BMP and JPEG are not exactly the best image formats out there.
  Image loading should almost certainly be left client side.

  I get the feeling in some places that the Micro/Nano* API is "small
  subset of  X and Windows plus random extra features that were easy
  to implement".

* There seems to be no attention to race conditions - for instance,
  there is no way of correlating expose events with CopyArea 
  calls.

* The Nano-X lib seems to mix the drawing commands together with the
  main loop into a single unit; this violates the separation of labor
  that every X toolkit relies upon.

* Some bad parts about X are preserved; to list a few:

  - Ellipses turned out to be nightmare to implement and get
    right in X. The right thing to do is to do beziers and approximate
    ellipses with beziers

  - Window borders in X are basically X10 legacy, are are universally
    not used.

 [ There is a paper "Why X Is Not Our Ideal Window System"  
   Software Practice and Experience, Volume 20, #S2 which has
   some useful commentary about problems that the X implementors
   found over time. ]

* The font API has no ability to make a character/glyph distinction.
  There are quite a few languages that to handle properly, this
  distinction needs to be exported to the client.

  The font API also seems to be very unclear about how it handles
  font styles and there is no way of getting a list of available
  fonts as far as I can tell.

I guess the lack of docs and the lack of clear interfaces bothers
'me most. "Lack of docs" may sound hypocritical coming from one
of the GTK+ maintainers, but we've found out the hard way that
when you don't document, you are creating problems for yourself.

And X is excellent in this area. 

Regards,
                                        Owen