On Wed, 18 Dec 2002, Andreas Beck wrote:
> > Which widget library? Some of your own or something more general? > > One of my own. Basically something to do away with an ugly TCL/Tk > script that is used to control eccet. The idea is to have something that > can nicely live side by side with other stuff on a GGI visual. > > Existing libs made that cumbersome to integrate, as I want several > LibGGI native windows that will display rendered 3D-stuff in realtime > and accept mouse and key commands _plus_ one or more control windows > - that may be as slow as they want - to give a GUI for stuff that is > not easily controlled with keyboard and mouse. [...] > I can send you the code if you like. It has some special widgets I happen > to like (e.g. dials like used in xv). I'm sure it is interesting and I'll certainly have a look at it, but don't you think that yet another custom widget library would not give problems to GGI (as a project)? Whatever the merits of your library (knowing your coding habits, I guess it should be pretty good anyway) I guess adopting a "preferred" widget library on top of GGI may involve a lot of hard thinking (and fatigue): 1- there several (possibly numerous) condidates for porting, each with their own merits/drawbacks (technical aspects, audience, available applications, etc.), and we should surely do a review first; 2- they probably all need a windowing system (maybe yours don't something that could be decisive in the short term); 3- the biggest drawback of GUI widget library X is certainly the fact that... it will not be library Y! (I mean: we will always find a user that does not like the one we adopted and wants another. And once someone has adopted one widget library, it seems he is pretty reluctant to try another one before several years.) 4- IMHO we should strive for a GUI system that can take advantage of all the advanced features made possible by the GGI architecture (transparency, alpha, 2D accel, 3D accel, multi-display, etc.) and I guess few existing candidates go so far (hence my comment about Berlin/Fresco) and even fewer are also widespread and feature-rich. Well, I'm pretty sure such a debate could turn easily into an unproductive flame. And, in the end, maybe many users, like you, would finally re-implement their *own* widget system for their own application (or give a lof of $$ to get Views.) I am playing the devil's advocate too here (in case you have not noticed :-). Of course, I'd love to see GTK, Qt, Amulet, your widget kit, or any other widget toolkit, available on GGI... and possibly all of them! However, I wonder if the GGI project should not also try to propose something else. Of course, this mean *I* am going to propose something else now... ;-) I have worked with some people in the field of ergonomy and UI design (note the absence of the 'G' these people insist a lot on this fact :-). And they really made me look at GUI toolkits in another light. Some of my work with OpenAmulet also made me think differently to what a developper should expect from a UI system. (Amulet was developped to support research in GUI toolkits at Carnegie Mellon.) And there were also a few things that made me think (the initial publications from project Athena in the 70s, a NeXT box, MacOS and its specs and the AppleIIGS, the SpaceOrb with DukeNukem, a presentation from Van Hamme, etc.). So even though I am far from being a specialist in this field, I tend to think that programmers do not always look at UI the right way, and my own requirements for a UI system would be: 1- For precise interface layout, I do not want to program: I simply want an UI builder. I do *not* care of the actual API involved below, I do not want to be able to call it directly. I want these damns buttons to get drawn, I do not want to know how and by which function. 2- I want to be able to inspect dynamically the UI system while it is running in the development phase. In fact, I want the "simulation" button of the UI builder to actually run a "-DUI_DEBUG" version of the final application (or something equivalent). This is because I think a good GUI should provide a GUI for debugging itself ;-), and because good UI design goes typically into a fast prototyping loop (try, improve, restart) and the best way to do it is by modifying a running version of the GUI (the GUI itself not the program functions of course). 3- I'd like to have some easy system to define the dynamic behavior of the UI elements: something like a state machine drawing program. I want default behaviors available, and I want these default behaviors to fully support undo/redo etc. (At the interface layer.) If possible, I'd like such behavior to scale to multi-user interactions (two mouse in two hands of *two* people). I do not want behavior to correspond to elementary GII events. 4- If my program does 10 things, I'd like the generated UI to call 10 C functions that do the real work in my program (or shell scripts, or Perl programs). Maybe 11. Not 100. 5- When the GUI involves editing of in-program data structures (for example: a configuration dialog, or a modeler, or a database form - passing parameters to function of 4 is a special case of this), I'd like to specify these data structures in something similar to a text-based programming language. Possibly the native programming language like C if possible, but I'd accept to use a custom data-oriented language. In this case I want this description to be converted automatically to C/C++ etc. to use in my own code. And I want the UI system to provide *automatically* some GUI elements for a user to edit them. In short: I do not want to deal with the UI-specific data structures or widgets, I only want to deal with my own data model and I authorize the UI system to interact with it but only the way I want. I totally refuse to change my data model to fit the needs of the GUI system. (Yep, currently, I have nearly abandonned GUIs. ;-) 6- I want to be able to program new GUI elements for the system at my will: give me a visual/subvisual/wisual whatever and input and I'll do all the work. (If my data structure is some ultra-specific data structure, like medical X-ray data, air traffic control data, satellite image acquisition signal, or the Bulgarian formula for importation taxes of fine art pieces, I know 5 will fail and I'll have to provide the "automatic" widget myself but well...) 7- If possible, I'd like the default elements of 5 to provide a well-defined set of parameters for customization of their look-and-feel (to give my application some originality, if I have time to do that). But well, for me this is optional, I'm not a fond of themes, and I believe that those who are fell in category 6 and had better re-develop GUI elements. (Of course, in my view, using these new elements is just a matter of re-generating the program via 1.) Note that in all these things: only 6 involves programming and API, only 7 involves library-oriented issues (and only parameters in my case), 1,2,3,4,5 involves a *program* (or probably a set of programs to do the various things). That's the way I feel it: maybe we should try to provide one (or several) GUI *generators*. These generators would themselves have: an UI and probably some input language. And then, in their internal mechanics, they would generate something that would involve either library X, Y or Z on GGI, or some custom library code or raw C generation (in the extreme case). Of course, there is a bootstrap problem here: which GUI to use for the UI generator... :-)) But I really believe the latter should be able to generate itself before claiming v.1! Well, enough dreaming, I promise I go back to programming at once... :-)) Rodolphe
