Hi Rodolphe, > > > Which widget library? Some of your own or something more general? > > One of my own.
> 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)? That's one of the reasons, why I didn't advertise about it. I wrote it to solve a particular problem I had, and I wanted it to be available fast. Reading through someone elses code would not have been compatible with that. Moreover I wanted something that fits my coding style. being forced to C++ or having to write down elaborate callback stuff or handling complex meta-messages wasn't quite what I wanted to work with. > Whatever the merits of your library (knowing your coding habits, I guess > it should be pretty good anyway) Not really. It's a hack, it's ugly, but it does it's job which is replacing Tcl/Tk in a few applications where Tcl/Tk sucks due to several limitations in widgets and in parsing answers from a TCP-Pipe. > I guess adopting a "preferred" widget library on top of GGI may involve I think I should stress, that this toy of mine is not at all intended to be the "preferred" widget lib. Maybe just a little tool that can be used to add a few widgets to some LibGGI programs that might just be better, if you had a handfull of buttons or a textbox. > 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; Yes - see the old QT/GTK quarrel ... > 2- they probably all need a windowing system (maybe yours don't > something that could be decisive in the short term); Yes. It doesn't. Basically it needs a rectangular area on a LibGGI Visual to attach to like this: ggiWidgetAttach(top,vis,0,0,512,512); > 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.) Right. However the only way around this would be to emulate X :-). > 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.) That wasn't quite my goal. I wanted a simple widget lib. > and I guess few existing candidates go so far (hence my comment about > Berlin/Fresco) and even fewer are also widespread and feature-rich. Right - Berlin/Fresco might be the way to go for that path. > 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.) :-) Right. > 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! Right - but we don't have the ressources to do that I think. > However, I wonder if the GGI project should not also try to propose > something else. Maybe - I don't know. While my hack is ugly, maybe someone comes up with that brilliant idea of his own, and we can all get famous by just making a GGI implementation which everyone will want to have, cause it is so cool, easy to use, easy to program for, feature-rich, ... *g*. > 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. Right. However I want to be able to tell that FSCKING builder how the buttons should react to resizing of the window, i.e. what area should expand and what should make way. I _hate_ that stupid static designs that will not make that stupidly small 40x4 Textareas that get on my nerves, because I want to enter quite an amount of text bigger when I pull the window bigger. > 2- I want to be able to inspect dynamically the UI system while it is > running in the development phase. Ack. That was a very cool feature of Amulet. > 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. Ack. However that will probably need some metalanguage to tell teh GUI part "if bla and blubb checkboxes are on and OK gets clicked, then call function do_that();". > 6- I want to be able to program new GUI elements for the system at my > will: give me a visual/subvisual/wisual whatever /me cheers. Right. That was one of the things I also wanted in my widgetlib. Didn't quite succeed, but it is good enough for me. Adding Widgets is pretty simple there and can be done without touching the library code. You just write code that fills out a ggi_widget_struct (with various callbacks) and ther you go. > 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, Neither am I. They tend to eat up Ressources in a) the Developers Brain and his timeline - at least if he hat to resort to 6 b) the User's machine c) the User's brain and work time (for fiddling around with the various themes just to find out the simple ones are most efficient). > 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! :-). Right. Well usual solution. Use an existing compile to compile, then compile again with the result. Repeat until no significant changes occur anymore :-). CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
