Hello,
sorry for not taking my part in the discussion earlier, but I'm catching
up slowly with my email inbox... :-( I hope the topic is still active.
If I understood correctly, ggitk may need a windowing system with
Xlib-like drawing functions, no ?
This is more or less my own requirements for LibGWT. Furthermore, these
requirements more or less originates from the OpenAmulet GUI library,
which is also a X11-rooted GUI library. So I guess a finished LibGWT
may be more or less adequate for ggitk. (Of course I don't know all the
details, so this is only my personal feeling.)
LibGWT furnishes "stackable drawing regions": i.e. low-level windows
(which may be complex regions, not only rectangles). Drawing functions are
also furnished for these windows - and I'm adding XMI-based drawing
functions (to have more drawing features). However, currently, all the
drawing functions are new library functions, named gwt* (or gwtmi*). [So,
a GWT window is not really similar to a LibGGI visual. IMO, such windows
could and should be made much more similar to a visual.]
There is one area where LibGWT _design_ may NOT satisfy ggitk
requirements:
- there is currently nothing dealing with any sort of "window
manager" inside LibGWT.
This could be problematic for a GUI library. For OpenAmulet it is not so
problematic, but for other GUI libraries, like GTK, it could be a problem.
I don't know.
There are _several_ areas where LibGWT in its current-state may not yet
satisfy ggitk requirements.
In short LibGWT is still really tagged "EXPERIMENTAL". For example, binary
compatibility between working CVS snapshots is not something to expect.
The API may change also (in fact, it _should_ change). If you want
something for production, well, it's not the ideal situation at all
(unfortunately).
In more detail, places where the implementation is still defective are:
- LibGWT still is a "regular" C library. It registers as a LibGGI
extension-lib, but it does not really uses the extension mechanisms. It
should - but then this could induce changes in the API and lots of
hackery. But in the end, the intent is to allow the application to call
ggiPutBox() directly on the "GWT-aware" visual.
- I started to add LibXMI-equivalent drawing functions inside LibGWT, but
this is not finished. It shouldn't be too hard however I think. In
practice, it is necessary to have such 2D drawing functions inside the
lib. for realistic work on a GUI (that's what I saw with Amulet: pixels
and boxes are not enough ;-).
- optimisation, reorganization, re-implementation are still only in my
plans, not to speak about documentation.
Do not hesitate to beat me again and again if you want some progress on
this. Honestly, I'm too lasy on this job. But I also need to have more
requests for features. At least, be sure that I welcome any external
contribution (Tristan Wibberley did so in the past and it was useful).
Do not hesitate to have a look at LibGWT, and tell me what you like, what
you do not like and what you'd like to see added next.
Rodolphe
