Re: World-Domination - was Re: multi threaded... Details: Names
On Fri, 20 Dec 2002, Rodolphe Ortalo wrote: I really think it is a very important point to get _applications_ using a GUI. I'd even say that it should be a requirement. But I understand that you may also have a lot of work to do to get the GUI essential elements running in Fresco... :-) Back to the thread I think this might have come from -- someone should look into making embedded Qt run on GGI if it doesn't already, and then verify that any available apps for embedded Qt work well. That would give us a *much* bigger app base. It would be *nice* if it could do so without requiring a directbuffer (though using one if available.) Too many GGI apps require a directbuffer -- even some that have no real reason to do so considering they have their own backbuffers. -- Brian
Re: World-Domination - was Re: multi threaded... Details: Names
On Thu, 19 Dec 2002, Stefan Seefeld wrote: I don't think an interactive GUI builder is an absolute must to get a GUI, [...] I really think it is a very important point to get _applications_ using a GUI. I'd even say that it should be a requirement. But I understand that you may also have a lot of work to do to get the GUI essential elements running in Fresco... :-) Rodolphe
Re: World-Domination - was Re: multi threaded... Details: Names
On Thu, 19 Dec 2002, Andreas Beck wrote: 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. You are rushing to issue 6 right away: you are a programmer. :-) You will probably find out later on that your grandma never noticed that feature; but complain all the times on the fact that buttons are not in alphabetical order. :-) 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 :-). On this issue, I wonder if we are not in the situation where no base system exist to perform the bootstrap. Well, the first compiler was written in assembler, but I do not think it was the most tricky part of the job. Designing a good high level programming language was probably more difficult. :-) I wonder if the guys from Berlin/Fresco have not already an opinion on this. Anyone on this list? Rodolphe
Re: World-Domination - was Re: multi threaded... Details: Names
Rodolphe Ortalo wrote: 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 :-). On this issue, I wonder if we are not in the situation where no base system exist to perform the bootstrap. Well, the first compiler was written in assembler, but I do not think it was the most tricky part of the job. Designing a good high level programming language was probably more difficult. :-) I wonder if the guys from Berlin/Fresco have not already an opinion on this. Anyone on this list? I don't think an interactive GUI builder is an absolute must to get a GUI, so it's not really a bootstrapping process. The old InterViews toolkit had an application based on the Unidraw framework to generate a GUI. They published a couple of papers to discuss how it worked. I'm now working (a bit) on a Unidraw port to fresco, so a GUI builder may be one of the sideeffects, if anybody is interested... Regards, Stefan
Widget lib - was Re: World-Domination - was Re: multi threaded...Details: Names
Which widget library? Some of your own or something more general? One of my own. How about uploading to our GGI ftp server and posting the URL here? Done. It's in the misc-directory. widget.tgz CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: World-Domination - was Re: multi threaded... Details: Names
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).
Re: World-Domination - was Re: multi threaded... Details: Names
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
Re: World-Domination - was Re: multi threaded... Details: Names
On Tue, 17 Dec 2002, Filip Spacek wrote: What I think is needed is a more evolved concept of a subvisual. The current one can only be used to create a rectangular viewport on an existing visual is unfortunately insufficient. What we need is a subvisual that can be defined by an arbitrary number of clipping regions. What we need is a core rework that allows cloning of entire visuals which will be useful for many purposes. This will involve quite some coding in all the target-specific code and addition core GGI API (e.g. ggiCloneVisual) though if we want it to work cleanly. Rectangular probably, but it would be pretty sweet if we could get the functionality of the X shape extension (not that I'm very familiar with it). Even more, what is needed is a means for a process to suply this clipping info. LibBuf is meant to take care of this using runlength encoded (actually there's a more complicated/efficient format used than simple runlength) stencil/Z buffers. With only the main visual this will be slightly tedious in that the stencil buffers must be detached/reattached when you switch windows. With multiple visuals as mentioned above each subvisual could have a different stencil buffer attached. Personally the dl system rewrite is higher on my TODO list than cloning visuals, however. -- Brian
Re: World-Domination - was Re: multi threaded... Details: Names
of minor importance, just to avoid duplication ;) - Hey, Marcus, i'm porting your synaesthesia ggi-driver to the current version. - Hey, Marcus, i'm after that svga4libggi of yours. Although you once pointed out it was just a hack, there is so much serious interest in it, it might become one of the secret weapons for world domination. I'm in contact with svgalib maintainers to coordinate the work of (real) svgalib, svgalib-dummy and ours to become a real fine solution. greetings, martin
Re: World-Domination - was Re: multi threaded... Details: Names
On Tuesday 17 December 2002 18:42, Christoph Egger wrote: Heh! Where do you get this messages from? Huh? This my own! martin
Re: World-Domination - was Re: multi threaded... Details: Names
Rodolphe Ortalo [EMAIL PROTECTED] wrote: crunching even badly structured code. GGI was _interesting_ - it gave something we didn't have on Linux yet, and it was _challenging_ to write Code for it. You are too negative. Right. I was playing advocatus diaboli. What about 2 independent applications sharing a single 3D engine? :-) - yeah - what about any two apps sharing the same graphics subsystem (apart from X) ;-). 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. The reason for eccet itself not using a widget library is speed. I want highspeed access to the graphics frontend (X). LibGGI provides that nicely for me. And I don't want to bother with some intermediate layer for a widget lib like GTK. I have sped up a simple application (planeview) by around one order of magnitude by just porting it over from GTK. And to my knowledge the original implementor had already played tricks to make it fast on GTK. 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). what about Berlin/Fresco? I have to admit, I havent looked at it lately ... CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: World-Domination - was Re: multi threaded... Details: Names
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. The reason for eccet itself not using a widget library is speed. I want highspeed access to the graphics frontend (X). LibGGI provides that nicely for me. And I don't want to bother with some intermediate layer for a widget lib like GTK. I have sped up a simple application (planeview) by around one order of magnitude by just porting it over from GTK. And to my knowledge the original implementor had already played tricks to make it fast on GTK. 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). How about uploading to our GGI ftp server and posting the URL here? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
