> 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 libggi<name>. (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 Chicken&Egg 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 it - by the very media - forces to keep things in a "tight" and simple to read form. I looked at a few of the IRC logs, and I couldn't make much sense of it. There were too many hellos/goodbyes and other stuff distracting from technical questions. IMHO such questions are better discussed in mail. Note that I am not advocating to close down the discussions on IRC - they may be helpful, and we traditionally used IRC to coordinate releases and make the big decisions, but IMHO IRC is too noisy for efficient communication in a large group. So please: If the IRC session come up with a question that cannot be solved ad hoc, or where someone feels it might be of public interest, or just thinks that a decision made there is significant enough: Just open another window, and push it to the ML - of course stripping out the line noise and possibly giving a little background. I will gladly try to follow the ML, but have _no time at all_ to watch IRC-Traffic. I am online at strange times (see Date:-Header) whenever I got a free minute, so only asynchronous channels are acceptable for me. I am afraid there might be others with similar restrictions. O.K. - no for the great plan: 1. Enhance communication - post more stuff to the ML. Advances, new apps, whatever. O.K. - don't spam it with "I corrected the spelling in the comment in ...", but ... 2. Make sure we can build fine and bugfree(TM) binary packages. Get them into the distributions. 3. Get yourself a project ready,that will use GGI. I already have mine. I'm working on making ECCET ready for being started from a Knoppix Run-Linux-from-a-single-CD Environment and will be trying hard to spread ECCET and thus GGI as well. I will probably release source to a few subsystems (3dscan e.g.) of it, thus maybe directing more attention to GGI. 4. Take every fscking application you find nice and provide it with a LibGGI target. Show maintainers why LibGGI is a cool thing to have. See my example about why GGI for mplayer rocks. 5. Push up the features. I _love_ GGI for the flexibility. One thing to push an edge further would be the file target. Allowing it to spit out a continous stream of ppms to a pipe would probably be a small matter of programming, but it could make available cool stuff like being able to record any LibGGI app output to MPEG with a 1-line script. Another cool thing would be the "rotate"-target we have talked about a few times. I have some LCD-Displays that are turnable, and I have an application that could use it ... If I find some time, that's something I'll try to tackle. 6. Give the users what they want: enhance the interfaces to make it more feasible to port given apps to it. 3D/games-related stuff is on that list. I also have a Widget-library in my work queue (stalled due to other priorities right now). If anyone want to have the code, I'll gladly send it along. If a few brave coders here take care of it it might quickly turn into something useful. Sound isn't quite in our domain, but we might want to give at least example code on how to integrate that ... uff - late now ... I'l better stop before I talk tooo much rubbish. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
