On Wed, 5 Jul 2000, Rodolphe Ortalo wrote:
>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.
>
yep :)
>If I understood correctly, ggitk may need a windowing system with
>Xlib-like drawing functions, no ?
>
yep :)
>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.]
>
Can libXMI just be used instead? Then I can get ahead sooner since much of
the fbdev port of gdk is on top of XMI.
>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.
>
Does OpenAmulet do this internaly? I remember you talking about OpenAmulet
before but decided to work with GTK+ since it is C based.
>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).
>
I will do what I can to help. Since I need it:) I will most likly be
porting GDK for the most part. Perhaps OpenAmulet could benifit as well.
Who knows?
>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.
Perhaps we could lay out a plan of attack here. It always good to plan
before leaping into the cravass!
> - 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 ;-).
Once I port GDK to libXMI and libGWT this is what would exist. I think
GTK+ sits entierly upon glib and GDK. glib has no windowing or drawing
functionality at all it, just data structures and threads.
> - 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).
>
Again perhaps we can get together on this and see what we can see. (i'll
let your wife beat on you though :)
>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.
>
>
Will do! I want to have all the flexability that exists under X on the
console as well if not more :)
>Rodolphe
>
>
>
- Bryan Patrick Coleman
UNCG
[EMAIL PROTECTED]
http://www.uncg.edu/~bpcolema
Octagram Linux
[EMAIL PROTECTED]
http://octagram.sourceforge.net
Questcon
[EMAIL PROTECTED]
http://www.questcon.com
