Ben Bacarisse said:
I probably have little credit in your bank, but if there is any left,
draw on it now and consider this question: does the world need yet
another X toolkit? I think not.
That's a good question. The idea of Baby X is that it is simple to use, at
the cost of not having much flexibility, and is also simple in code.
Initially it seemed to go very well, you can have scrollbars, buttons, edit
fields etc, all perfectly serviceable, in a few lines. Unfortunately adding
containers broke the premise that "each object is a window" of its own type,
whilst fonts and colours make things more complicated, and introduce
dependencies of the objects on each other. As I add functionality, it
becomes progressively more and more difficult to descibe how to write your
own BabyX component. Eventually it might end up as just another toolkit, so
the question becomes why not just use GTX?
What would be hugely useful is a simple C API to a common abstraction
(a simple subset, presumably) of the basic GUI functionality with
small back ends that implement this natively in Gtk, Qt, Win32 and
anything else anyone fancies. I don't know if this is really
possible, but if it is it would benefit everyone doing cross-platform
development of GUI C programs.
It is easy to define an interface. All you need is openwindow(width,
height), closewindow(), setpixel(x, y, colour), arguably getpixel(x, y),
querymouse(win, &x, &y), and squeaksqueak( void (*fptr)(int buttons, void
*ptr)), defiining a callback for mouse input, and kbhit() / getch() for the
keyboard.
In practise it is difficult to get this to work on all systems, because they
evilly take control of the main loop. That was another motive for writing
Baby X. Then you've got the problem of colour depth, not so severe now but a
real nuisance in the past. Finally you really need some hook into the
systems fonts. You can get output without it, but non-game users like to see
Ariel and Times New Roman.
Another problem again no longer as severe as it was, is that on some systems
there isn't enough memory to hold backing store for every window. So windows
need to be regenrated on demand.
The of course you can't write a non-trival GUI with just those functions,
you need sub-windows and other facilities on top. However you can implement
everythign in terms of simple pixel operations. Java's Swing does just
that - the previous approach, providing interfaces to native graphics calls,
failed.
