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!
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. After three days of psycho rollercoaster between putting it all in one package, giving up on it and having lots of packages nicely split, i had to decide that there is not much that i can do from my side _now_ to put all this on a stable basis within a short term. This one is libggi0-target-x now, proposing the illusion of the possiblility to have more than one generation of libsmods installed. Anyway, i'm not giving up and hope that we are able to find a midterm solution. /me started to put a script together, quoting the problems that i actually have and can see and we can try to fill in solutions. Mind you, the number of packages depending on libggi is sinking continously ... !!! So for the very moment i have only ONE point that I BEG should be tackled BEFORE any RELEASE: Please, consider how you really want to call your libs and extensions wrt. filenames! What a nice plug, that even one of your core dev's had to find that the name of any lib had silently changed - and that from the name, that i think would be fine to the one that is, from my POV, not feasible to hold up. I'm still holding the upload of libgcp and wmh because of this reason. Call it libggiextwmh if you like that, but go for it. I really like the ideas behind GGI and how you do your project. I try to find a way to promote it's use wo. it having to become too professional. Soon even Debian/BSD might become a reality ... I really don't know what is so hard to understand about my questions and the cases that i bring up to you as The Project. I'm really sorry if i make you feel uncomfortable from time to time ... Again, i have my structures set up here so that i can put out _any_ of your libs in a short time, either from cvs or your tarballs. Getting it all right from Linux binary compatibility, shlibs issues, over Debian policies to the ggi project isn't the easiest thing to do if you pay 2 cents for each minute of internet connectivity. Besides getting the svgalib wrapper going, this is what i see as my part to give sth. back to you. But i know now, how much work it is to keep a ggi application going over time and i'm not willing to promote that to anybody who tries to get sth. else going too. /me now has to get sth. else going too, thanks for your time. Have a nice GGI, have a nice day, martin
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). Well, ok... When there are no objections within the next 6 hours, I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp, libvideo, libxmi, etc.) to the form of libgginame. (i.e. libggigpf, libggigic, libggibse, libggigalloc, libggibuf, libggiovl, etc.) As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. After three days of psycho rollercoaster between putting it all in one package, giving up on it and having lots of packages nicely split, i had to decide that there is not much that i can do from my side _now_ to put all this on a stable basis within a short term. This one is libggi0-target-x now, proposing the illusion of the possiblility to have more than one generation of libsmods installed. Anyway, i'm not giving up and hope that we are able to find a midterm solution. /me started to put a script together, quoting the problems that i actually have and can see and we can try to fill in solutions. Mind you, the number of packages depending on libggi is sinking continously ... !!! I'm really wondering, what is WRONG with GGI... People seem to like the idea making the same efforts/work again and again on various projects by porting them to this and that plattform... So for the very moment i have only ONE point that I BEG should be tackled BEFORE any RELEASE: Please, consider how you really want to call your libs and extensions wrt. filenames! see above. What a nice plug, that even one of your core dev's had to find that the name of any lib had silently changed Well, Andy is the GGI founder, but core developer? hmm... ex core developer or core user seems to fit better... Sorry, Andy, but that is the picture about you you give us with your absence... Correct me, if I am wrong... I really don't know what is so hard to understand about my questions and the cases that i bring up to you as The Project. I'm really sorry if i make you feel uncomfortable from time to time ... No. We need people like you, who point us to the right direction... :) Again, i have my structures set up here so that i can put out _any_ of your libs in a short time, either from cvs or your tarballs. Getting it all right from Linux binary compatibility, shlibs issues, over Debian policies to the ggi project isn't the easiest thing to do if you pay 2 cents for each minute of internet connectivity. Ouch... Don't you have the ISDN XXL tariff? You can surf with no costs on Sunday's then... :) Besides getting the svgalib wrapper going, this is what i see as my part to give sth. back to you. But i know now, how much work it is to keep a ggi application going over time and i'm not willing to promote that to anybody who tries to get sth. else going too. /me now has to get sth. else going too, thanks for your time. The official maintainer of the svgalib wrapper is still Marcus Sundberg. I wonder, where he remains... Is there any volunteer taking over the maintainership? -- 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!
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). Well, ok... When there are no objections within the next 6 hours, I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp, libvideo, libxmi, etc.) to the form of libgginame. (i.e. libggigpf, libggigic, libggibse, libggigalloc, libggibuf, libggiovl, etc.) I am done with that now. All is in CVS. libwmh and libgcp are repackaged (see http://www.ggi-project.org/modules.html) Martin: Now again, it is your turn :) -- 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!
Re: multi threaded... Details: Names
libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). I'd as well say, it's an aesthetic issue. The only thing that differntiates an extension from a lib that merely uses libGGI is, that extensions tend to be locked to a specific LibGGI version as they have access to internal structures. Mind you, the number of packages depending on libggi is sinking continously ... !!! That's bad, but no wonder. I will detail on this in another post. Please, consider how you really want to call your libs and extensions wrt. filenames! What a nice plug, that even one of your core dev's had to find that the name of any lib had silently changed Yeah well. Maybe some misunderstanding. It has been rolled back to libggiwmh, which is IMHO a good thing to avoid namespace pollution. If all Libs that are clearly dependent on LibGGI and originate form the GGI project carry a ggi in the name, this might actually promote the term GGI further and it seems to cause the fewest problems with namespace as well. and the cases that i bring up to you as The Project. I'm really sorry if i make you feel uncomfortable from time to time ... No - you are very right to make us feel uncomfortable from time to time. We usually deserve it. I already took some slapping with a red haddock from Christoph earlier that day, for dropping silent for so long, and I think I also deserved that. The misunderstanding with wmh could have been avoided easily, if we would communicate better. I'll detail on that now in another post. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
World-Domination - was Re: multi threaded... Details: Names
Well, ok... When there are no objections within the next 6 hours, I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp, libvideo, libxmi, etc.) to the form of libgginame. (i.e. libggigpf, libggigic, libggibse, libggigalloc, libggibuf, libggiovl, etc.) No objection from me. See my previous post about polluting namespace. We have alloced a nice slice libggi* and should stick to it. This doesn't matter much to completely unrealted packages that third parties might want to base on libggi*, but it really helps keeping things together for the packages _we_ are responsible for. Mind you, the number of packages depending on libggi is sinking continously ... !!! I'm really wondering, what is WRONG with GGI... Some simple reasons: We are too cumbersome to install. Having debian packages will help a great deal there. I wonder if my old Redhat packaging scripts still work. They are ugly, but usually did the job. If they don't, we might want to try alien on the .debs, or give me a kick to try to update them. I still have a few redhat boxes around (though I'm shifting to debian as well - apt-get is much less annoying then the rhn-stuff), so it should be doable. People seem to like the idea making the same efforts/work again and again on various projects by porting them to this and that plattform... Right. But we drive them there. As Jos already pointed out: * There are alternatives that are portable enough for most and that have a * consistent and usable API, don't consist of a maze of many libs, provide * 3D accelleration (or at least abstraction of it) and sound abstraction * (essential for games) ? Right. Jos is pointing towards SDL. SDL is similar in many ways to GGI, but gives a more complete solution. It is less lean and less modular, but then again that is no issue for many applications. It has a huge advantage over ggi, apart from having more features that do not strictly relate to graphics: It is available on almost every distribution. This is a ChickenEgg problem. If there aren't many apps, noone includes the Lib in the distro. If the Lib isn't in the dist, noone notices it and thus noone writes apps. Well, Andy is the GGI founder, but core developer? hmm... ex core developer or core user seems to fit better... Sorry, Andy, but that is the picture about you you give us with your absence... Correct me, if I am wrong... No, you are right. I am well away from being a core developer of GGI. I help out with patches and little bits, as I get bitten by bugs in GGI. I am actively using it for a very demanding application (www.eccet.de), but my current taskload leaves little room to play around with other stuff. I had hoped Christoph would fill my place as a project leader while I am hindered, or even permanently, and he already does so to quite some extent. And I also see, that he is in a much worse position than I used to be: When GGI was you, graphics on Linux was something exciting, new. And hardware wasn't that overly powerful, that you could just take some strange highlevel toolkit, drop in a scenery and get a 3D rendering from it. in realtime, just because the hardware was so good at 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. I think that is, what is lacking now, thus making development slower than in the good old days. Now for another valid point from Jos' mail: /me thinks that compiling the ggi stuff is a hell: First this tiny sublib (gii), then the next (ggi) then number three (galloc) then all extensions some of which are no extensions ... Right. That again calls for binary packages and maybe even an installer package that will query the user and the system and then select the right subpackages. I don't like to compile libs just to _use_ them as well. I resort to it, when I _have_to_ - e.g. when the libs are buggy and I got to hunt that down. Besides ,I have never seen any advertising for GGI, it is not known on linuxgames, the last entry on freshmeat dates years back. I think I remember one interview in which ggi was mentioned, but that was years ago. Right again. We are not visible enough. Why is this? Simple: We lack applications. We have to provide as many apps as possible to get things started. So folks: If you code a simple demo, some eye-candy, whatever - put it up on freshmeat, so folks get that, and consequently get LibGGI. But do so only after we have working binary packages out there to make installation smooth. next point: Communication. Christoph pointed me to the IRC logs today. I didn't even know they existed! However that is IMHO not a good way for communicating in large groups, especially if they are scattered in different timezones. I'd like to have _the_essence_ going through the ML - it reaches more people, and
Re: multi threaded... Details: Names
On Sat, 14 Dec 2002, Filip Spacek wrote: On Sat, 14 Dec 2002, Martin Albert wrote: Sorry, if you find i'm insisting or sth. like that. I feel that i have unsolved problems (some more?: eg. module-versioning). Tell me to shut up or to try to do more mindreading about authors reasons for those choices (am i not correct with: building up GGI, concentrating on writing fine libs for the project with easy names, ...) I think your statement is correct and valid. I think libggiwmh has it all: distinction, elegance, few chars to type. Neither variant seems to be able to make both of us happy. Either i'm confused or there are unsolved issues that confuse (me). Decisions should be made before going further with release. Lay out a stable concept with v.2 giving developers a clear view of a stable GGI. Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht einfacher. Keep things as simple as possible, but not simpler! If you don't take sth. upon yourself, somebody else _will have to_. greetings, martin (packaging gii, splitting x and really wondering / worrying about module-versions. libgii-target-x or libgii0-target-x is the question here, together with etc/ggi, lib/ggi all along). Well, I suppose my comment was directed more to authors of various extensions about the rather cryptic names of these extensions. Currently there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl in various stages of development. Maybe I'm just slower than most but meanings of a lot of these don't seem obvious to me. IMHO, flagging them as ggi extension by prepending their name with ggi is certainly a step in the right direction. libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. Ack. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: multi threaded... Details
Christoph Egger wrote: On Sat, 14 Dec 2002, Andreas Beck wrote: [...] I have tested these changes with my application, and it fixes the problems I reported. Could you please go over the code and my comments and have a look, if the fix is right? That stuff is pretty complex to think into, so I am not absolutely positive I didn't mis anything. If a few people confirm my thought, I will commit. I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. And your patch works fine for me, so far... Good work! I've tested this and it works fine for me with Fresco, after prompting from bughunter^WChristoph that it might fix the current problem we have with the rc's. It didn't, but it didn't break anything either :) -- Neil
Re: multi threaded... Details
Neil Pilgrim [EMAIL PROTECTED] wrote: I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. I've tested this and it works fine for me with Fresco, after prompting from bughunter^WChristoph that it might fix the current problem we have with the rc's. It didn't, but it didn't break anything either :) Good. That's two thumbs up now. Commited. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote:
I spent quite a while thinking this code through, and suppose I got it
right. I am not quite sure about the last two ifs in each chain. I think one
could use greater/less-or-equal in the comparisions as well, thus correctly
handling regions that just touch the borders.
/me hangs his head
Shame on me for being a cut-and-paste monkey and not revisiting that code.
All the changes look fine to me. Thanks a bunch!
BTW, on my TODO list is a helper library that does dirty-region tracking,
but it is something I probably won't get to for a long while. There
are other targets that could use dirty region management (e.g. tile).
If this sounds like an interesting diversion for anyone they are
welcome to take it off my hands :-). It is quite a fun challenge
for those of us who enjoyed algorithms 101.
The API would be something like this:
/* Initialize a helper instance and return a handle to it. */
dirty_handle = dirtyhelper_init(max_regions, cost_per_blit, cost_per_pixel,
do_blit_function_pointer, max_budget);
max_regions:A user-definiable cap on the number of dirty-regions tracked
cost_per_blit: How many points does sending a blit command cost, not including
the cost of the pixel data payload.
cost_per_pixel: How many points should be calculated per pixel when figuring
out the cost of sending the pixel data payload.
do_blit_function_pointer: A pointer to a function that unconditionally
blits a region from the backbuffer to the front-buffer.
max_budget: A limit on the number of points the dirty region manager
is allowed to accumulate.
dirtyhelper_exit(handle) /* Frees the instance and destroys the handle */
/* Mark a region dirty, but don't blit any regions. This means even if
it is horribly inefficient to do so, when the function returns all
the dirty data should be contained in = max_regions rectangles. */
void dirtyhelper_dirty(handle, x, y, w, h);
/* The manager adds the allowance to it's accumulated point budget. Then,
it has the option of blitting some data to the screen in order to
more efficiently fit the new region into its rectangles. The
manager must subtract the cost of that blit from it's total bugdet,
which must remain above 0.
*/
void dirtyhelper_dirty_blit(handle, x, y, w, h, allowance);
/* These are the same, for marking a region clean, e.g. when an accelarated
solid-fill primitive overwrites dirty pixels before they were moved to the
front-buffer. */
void dirtyhelper_clean(handle, x, y, w, h);
void dirtyhelper_clean_blit(handle, x, y, w, h, allowance);
/* Just let the dirty-region manager do some internal reorganization
and blitting, without making anything new dirty or clean. */
void dirtyhelper_blit_some(handle, allowance);
/* Flush all dirty regions. */
void dirtyhelper_blit_all(handle);
/* Explicitly set the number of points the dirty-region manager has
available to spend. */
void dirtyhelper_budget(handle, budget);
Targets would have the option of using
dirtyhelper_blit_some/dirtyhelper_{clean|dirty}_blit or just
using dirtyhelper_blit_all depending on their requirements.
Network based targets might also appreciate the ability to tune the
costs at runtime to adjust for dynamic latency/bandwidth ratios.
--
Brian
P.S. It boggles my mind that any of the X targets actually work
in a threaded environment :-)
Re: multi threaded... Details
Neil Pilgrim [EMAIL PROTECTED] wrote: I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. I've tested this and it works fine for me with Fresco, after prompting from bughunter^WChristoph that it might fix the current problem we have with the rc's. It didn't, but it didn't break anything either :) Good. That's two thumbs up now. Commited. Great! Tnx a lot. I just verified the patch successfully under MacOSX/PPC32. -- 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!
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote: Yet another update: 3. One of my applications doesn't correctly update its windows. It draws a picture and then a crosshatch above it and a small figure that can be moved together with the crosshatch. Moving down works fine while moving up/left leaves old crosshatch marks on the screen. That seems to be a real bug. The picture is set by calling ggiPutPixel, while the crosshatch is drawn using ggiDrawHLine and VLine. The Fun Thing is, that when I turn off the crosshatch everything is fine. When turning it back on, everything below the HLine stops updating - the VLine as well as the PutPixels. This goes away, if I use either -noaccel or -nobuffer. Another issue is seen when running a multithreaded part of the app: A visual is written to by two threads, each one calling ggiFlushRegion(state.visrender,0,y,rarg-w,1); for each line the thread has rendered. Funnily I test on a single-proceessor system, and I observe that only the _SECOND_ thread I start sometimes (about 1/3rd of the lines) fails to update the line. This goes away, if I use -nobuffer, but will stay when using -noaccel. Sounds like a broken MIT-SHM X extension. Please check out -noshm, -nobuffer:-noshm and -noaccel:-noshm CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: multi threaded... Details
[Crosshatch/HLine disturbs update of region below] This goes away, if I use either -noaccel or -nobuffer. Sounds like a broken MIT-SHM X extension. Please check out -noshm, -nobuffer:-noshm and -noaccel:-noshm Test results: -noshm doesn't change anything. The combination -nobuffer:-noshm works (as it does with shm on) The combination -noaccel:-noshm also works. Compared to the previous results, using shm does not seem to influence results [two threads Flushing Lines simultaneously] This goes away, if I use -nobuffer, but will stay when using -noaccel. Same findings here. Works fine when -nobuffer is active, forgets some updates when no options are given or -noaccel is active. Combining with -noshm does not seem to have any effect on any of the three cases. My guess is, that the dirty region tracking code gets messed up by the Hline. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: multi threaded... Details
Forgot to mention - X server is XGGI running on top of matrox-fbdev. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: multi threaded... Details: Names
Oh, no, not that again ...! ;-) Yet it must be. Christoph Egger on Friday 13 December 2002 21:24: Wann wird -rc5 ueberhaupt via aptget downloadbar? Packages are ready. I haven't uploaded, 'cause i don't like them yet. All that strange names ... On Saturday 14 December 2002 02:35, Andreas Beck wrote: 2. LibWMH is totally broken for me. This seems to be a binary compatibility issue, as the demo runs fine. O.K. - got that one. Library name changed from libggiwmh to libwmh. I am usure what I prefer. However for compatibilty reasons I would suggest to place symlinks to emulate the old name libggiwmh for some time. No, this looks nice, i'm sure what i prefer! That's what i like. libggimisc already exists like that, source, binary and libname are identical - that's the way to go! IMHO publishing these libs of yours with that generic names will not work in the long run at least. So, why don't you just do _that_?: call it libggiwmh, libggiovl, ... leaving gii and ggi itself like they are. Do it, i need one hour to redo the packaging and off it goes ... :) Please consider it. (Still ;) have a nice day, martin -- Use dselect for user-friendly package management
Re: multi threaded... Details: Names
On Sat, 14 Dec 2002, Martin Albert wrote: Oh, no, not that again ...! ;-) Yet it must be. Christoph Egger on Friday 13 December 2002 21:24: Wann wird -rc5 ueberhaupt via aptget downloadbar? Packages are ready. I haven't uploaded, 'cause i don't like them yet. All that strange names ... On Saturday 14 December 2002 02:35, Andreas Beck wrote: 2. LibWMH is totally broken for me. This seems to be a binary compatibility issue, as the demo runs fine. O.K. - got that one. Library name changed from libggiwmh to libwmh. I am usure what I prefer. However for compatibilty reasons I would suggest to place symlinks to emulate the old name libggiwmh for some time. No, this looks nice, i'm sure what i prefer! That's what i like. libggimisc already exists like that, source, binary and libname are identical - that's the way to go! IMHO publishing these libs of yours with that generic names will not work in the long run at least. So, why don't you just do _that_?: call it libggiwmh, libggiovl, ... leaving gii and ggi itself like they are. Do it, i need one hour to redo the packaging and off it goes ... :) Personally, I would prefer something like libggi_window_manager_hints.so, because I don't quite see the need for shortening the name. And this goes for all extensions: libggi_descriptive_name_of_the_extension.so. Currently, I have absolutely no idea what half of the acronyms stand for, and really, I don't think there's any need to use few characters. As far as I know, none of the OSs that libggi supports have stringent limits on the number of characters in the name and the amount of typing saved by shortening it is really minimal. On the other hand, I didn't write any of the extensions, so I shouln't be questioning authors' choices of names. -Filip
Re: multi threaded... Details
My guess is, that the dirty region tracking code gets messed up by
the Hline.
Confirmed the GGI_X_CLEAN-Macro contains a bug (I think, it is pretty
had to understand) Diff attached, please validate before I commit.
Rationale for the changes:
Old code was:
#define GGI_X_CLEAN(vis, _x, _y, _w, _h) do { \
if (priv-dirtytl.x = _x priv-dirtybr.x = _x + _w-1) {\
### If the to be cleaned region is at least as wide as the dirty region,
### it can possibly be used to clip the region down.
if (priv-dirtytl.y = _y priv-dirtybr.y = _y + _h-1) { \
### If it completely conceals the dirty region, turn off the dirty region.
### further processing can be stopped here.
priv-dirtytl.x = 1; priv-dirtybr.x = 0; break; } \
if ((priv-dirtybr.y _y) || (priv-dirtytl.y _y + _h-1)) break; \
### If the region is completely outside of the dirty region (i.e. starts
### below it or stops above it, nothing happens. Stop processing.
if ((priv-dirtybr.y _y + _h-1) (priv-dirtytl.y _y)) break; \
### Now here is the first bug. I think this is supposed to check, if
### the cleaned reagion is completely within the dirty region, in which
### case nothing can be done (it would split the region in two
### However it does check, that the cleaned region contains the dirty
### one. Correct code would IMHO be:
++if ((priv-dirtybr.y _y + _h-1) (priv-dirtytl.y _y)) break; \
### Mind the reversed comparisions.
if (priv-dirtytl.y _y) priv-dirtybr.y = _y; \
### Now we want o check, if it overlaps at the top or the bottom.
### This is inaccurate IMHO. The line y is cleared, so we can set y-1.
++if (priv-dirtytl.y _y) priv-dirtybr.y = _y-1;
if (priv-dirtybr.y _y + _h-1) priv-dirtytl.y = _y + _h-1; \
### Same here. y+h-1 is the last line that is cleaned, so we can start
### one line below, i.e.
++if (priv-dirtybr.y _y + _h-1) priv-dirtytl.y = _y + _h;
break;\
### is redundant here. We are in while(0), so we will autobreak anyway.
} else if (priv-dirtytl.x = _x priv-dirtybr.x = _x + _w-1) { \
### Uh - ouch. Next bug I think. I suppose this section is supposed
### to check the same but snipping off at left and right. For that to
### work, we should check the y parameters. I.e.
++ } else if (priv-dirtytl.y = _y priv-dirtybr.y = _y + _h-1) { \
if (priv-dirtytl.x = _x priv-dirtybr.x = _x + _w-1) { \
priv-dirtytl.x = 1; priv-dirtybr.x = 0; break; } \
### This is redundant, as the check in the area above would have catched it.
if ((priv-dirtybr.x _x) || (priv-dirtytl.x _x + _w-1)) break; \
### Check cleans left/right of dirty region.
if ((priv-dirtybr.x _x + _w-1) (priv-dirtytl.x _x)) break; \
# Check for completely contained region. Wrong like above.
++if ((priv-dirtybr.x _x + _w-1) (priv-dirtytl.x _x)) break;
if (priv-dirtytl.x _x) priv-dirtybr.x = _x; \
if (priv-dirtybr.x _x + _w-1) priv-dirtytl.x = _x + _w-1; \
# Comments like above leading to
++if (priv-dirtytl.x _x) priv-dirtybr.x = _x-1; \
++if (priv-dirtybr.x _x + _w-1) priv-dirtytl.x = _x + _w; \
break;\
# redundant.
}} while (0)
I spent quite a while thinking this code through, and suppose I got it
right. I am not quite sure about the last two ifs in each chain. I think one
could use greater/less-or-equal in the comparisions as well, thus correctly
handling regions that just touch the borders.
I have tested these changes with my application, and it fixes the problems
I reported.
Could you please go over the code and my comments and have a look, if the
fix is right? That stuff is pretty complex to think into, so I am not
absolutely positive I didn't mis anything.
If a few people confirm my thought, I will commit.
CU, Andy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
? bla
Index: include/ggi/display/x.h
===
RCS file: /cvsroot/ggi/ggi-core/libggi/include/ggi/display/x.h,v
retrieving revision 1.3
diff -u -r1.3 x.h
--- include/ggi/display/x.h 12 Jun 2002 03:53:59 - 1.3
+++ include/ggi/display/x.h 14 Dec 2002 15:01:25 -
@@ -208,18 +208,14 @@
if (priv-dirtytl.y = _y priv-dirtybr.y = _y + _h-1) { \
priv-dirtytl.x = 1; priv-dirtybr.x = 0; break; } \
if ((priv-dirtybr.y _y) || (priv-dirtytl.y _y + _h-1)) break; \
- if ((priv-dirtybr.y _y + _h-1) (priv-dirtytl.y _y)) break; \
- if (priv-dirtytl.y _y) priv-dirtybr.y = _y; \
- if (priv-dirtybr.y _y + _h-1) priv-dirtytl.y = _y + _h-1;\
- break; \
-} else if (priv-dirtytl.x = _x priv-dirtybr.x = _x + _w-1) {\
- if
Re: multi threaded... Details: Names
On Saturday 14 December 2002 15:06, Filip Spacek wrote: Personally, I would prefer something like libggi_window_manager_hints.so, because I don't quite see the need for shortening the name. And this goes for all extensions: libggi_descriptive_name_of_the_extension.so. Currently, I have absolutely no idea what half of the acronyms stand for, and really, I don't think there's any need to use few characters. As far as I know, none of the OSs that libggi supports have stringent limits on the number of characters in the name and the amount of typing saved by shortening it is really minimal. Because_this_is_neither_windows_NorAda.extend.here.at.will. I receive complaints about things not being readable on 80x25. I ended up with pkg name: libggi2-libwmh0-target-x-dev, could be libggiwmh0x-dev, libggi2svga On the other hand, I didn't write any of the extensions, so I shouln't be questioning authors' choices of names. -Filip Sorry, if you find i'm insisting or sth. like that. I feel that i have unsolved problems (some more?: eg. module-versioning). Tell me to shut up or to try to do more mindreading about authors reasons for those choices (am i not correct with: building up GGI, concentrating on writing fine libs for the project with easy names, ...) I think your statement is correct and valid. I think libggiwmh has it all: distinction, elegance, few chars to type. Neither variant seems to be able to make both of us happy. Either i'm confused or there are unsolved issues that confuse (me). Decisions should be made before going further with release. Lay out a stable concept with v.2 giving developers a clear view of a stable GGI. Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht einfacher. Keep things as simple as possible, but not simpler! If you don't take sth. upon yourself, somebody else _will have to_. greetings, martin (packaging gii, splitting x and really wondering / worrying about module-versions. libgii-target-x or libgii0-target-x is the question here, together with etc/ggi, lib/ggi all along).
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote: My guess is, that the dirty region tracking code gets messed up by the Hline. Confirmed the GGI_X_CLEAN-Macro contains a bug (I think, it is pretty had to understand) Diff attached, please validate before I commit. Rationale for the changes: Old code was: [...] I spent quite a while thinking this code through, and suppose I got it right. I am not quite sure about the last two ifs in each chain. I think one could use greater/less-or-equal in the comparisions as well, thus correctly handling regions that just touch the borders. I have tested these changes with my application, and it fixes the problems I reported. Could you please go over the code and my comments and have a look, if the fix is right? That stuff is pretty complex to think into, so I am not absolutely positive I didn't mis anything. If a few people confirm my thought, I will commit. I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. And your patch works fine for me, so far... Good work! BTW: Eric added a ggiGetCharSize manual page and documented the stuff you mentioned. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: multi threaded... Details: Names
On Sat, 14 Dec 2002, Martin Albert wrote: Sorry, if you find i'm insisting or sth. like that. I feel that i have unsolved problems (some more?: eg. module-versioning). Tell me to shut up or to try to do more mindreading about authors reasons for those choices (am i not correct with: building up GGI, concentrating on writing fine libs for the project with easy names, ...) I think your statement is correct and valid. I think libggiwmh has it all: distinction, elegance, few chars to type. Neither variant seems to be able to make both of us happy. Either i'm confused or there are unsolved issues that confuse (me). Decisions should be made before going further with release. Lay out a stable concept with v.2 giving developers a clear view of a stable GGI. Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht einfacher. Keep things as simple as possible, but not simpler! If you don't take sth. upon yourself, somebody else _will have to_. greetings, martin (packaging gii, splitting x and really wondering / worrying about module-versions. libgii-target-x or libgii0-target-x is the question here, together with etc/ggi, lib/ggi all along). Well, I suppose my comment was directed more to authors of various extensions about the rather cryptic names of these extensions. Currently there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl in various stages of development. Maybe I'm just slower than most but meanings of a lot of these don't seem obvious to me. IMHO, flagging them as ggi extension by prepending their name with ggi is certainly a step in the right direction. As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. -Filip
Re: multi threaded... Details
1. The X target seems to use a proportional font now. I was wrong on that. However it is using a 6x13 font now. I have fixed my app to properly check the font size now, but: The font size cannot be determined before the mode is set, which is pretty annoying, as I want to size a window to hold 5 Lines of text ... Code snippet: state.info=ggiOpen(NULL); [...] ggiSetFlags(state.info , GGIFLAG_ASYNC); ggiGetCharSize(state.info,metastate.ggifontsizex,metastate.ggifontsizey); fprintf(stderr,CS: %d %d\n,metastate.ggifontsizex, metastate.ggifontsizey); err=ggiSetSimpleMode(state.info,320, metastate.infoheight*metastate.ggifontsizey,1,GT_AUTO); ggiGetCharSize(state.info,metastate.ggifontsizex,metastate.ggifontsizey); fprintf(stderr,CS: %d %d\n,metastate.ggifontsizex, metastate.ggifontsizey); This snipped says on stderr: CS: 8 8 CS: 6 13 I suppose you get the point ... My application recovers nicely, as it resizes and reallocs windows on the fly anyway, but others might be less lucky. If at all possible, it would be nice to have ggiGetCharSize information available before mode set. And we should document if it can be called on a visual that doesn't have a mode set. As I can clearly see the problems with that, I would suggest that we just clearly document, that a) Font sizes _have_ to be queried, as we really use different fontsizes for different targets now b) Font sizes are only available after modeset, and that applications will have to resize/reset modes accordingly if they want to e.g. open a window with exactly 5 Lines of text in it. Obviously b) might induce recursion, so we should probably warn users about that or define a clear policy abou if and how far recursion can go. 2. LibWMH is totally broken for me. This seems to be a binary compatibility issue, as the demo runs fine. O.K. - got that one. Library name changed from libggiwmh to libwmh. I am usure what I prefer. However for compatibilty reasons I would suggest to place symlinks to emulate the old name libggiwmh for some time. using the current LibGGI. Issues are: Setting window title does not work at all, as does window positioning. For some strange reason reading windowsize also seems to get wrong, which makes a window as big as the screen as soon as I check and update its size. All solved by cleaning up the mess that rose form the name change (old library loading and calling new targets and stuff ... ). 3. One of my applications doesn't correctly update its windows. It draws a picture and then a crosshatch above it and a small figure that can be moved together with the crosshatch. Moving down works fine while moving up/left leaves old crosshatch marks on the screen. That seems to be a real bug. The picture is set by calling ggiPutPixel, while the crosshatch is drawn using ggiDrawHLine and VLine. The Fun Thing is, that when I turn off the crosshatch everything is fine. When turning it back on, everything below the HLine stops updating - the VLine as well as the PutPixels. Another issue is seen when running a multithreaded part of the app: A visual is written to by two threads, each one calling ggiFlushRegion(state.visrender,0,y,rarg-w,1); for each line the thread has rendered. Funnily I test on a single-proceessor system, and I observe that only the _SECOND_ thread I start sometimes (about 1/3rd of the lines) fails to update the line. This isn't strictly critical, but pretty ugly. Hmm - just looked around a bit ... can't find anything in the X target code. Maybe too tired. Will look deeper tomorrow. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: multi threaded... Details
Yet another update: 3. One of my applications doesn't correctly update its windows. It draws a picture and then a crosshatch above it and a small figure that can be moved together with the crosshatch. Moving down works fine while moving up/left leaves old crosshatch marks on the screen. That seems to be a real bug. The picture is set by calling ggiPutPixel, while the crosshatch is drawn using ggiDrawHLine and VLine. The Fun Thing is, that when I turn off the crosshatch everything is fine. When turning it back on, everything below the HLine stops updating - the VLine as well as the PutPixels. This goes away, if I use either -noaccel or -nobuffer. Another issue is seen when running a multithreaded part of the app: A visual is written to by two threads, each one calling ggiFlushRegion(state.visrender,0,y,rarg-w,1); for each line the thread has rendered. Funnily I test on a single-proceessor system, and I observe that only the _SECOND_ thread I start sometimes (about 1/3rd of the lines) fails to update the line. This goes away, if I use -nobuffer, but will stay when using -noaccel. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
