> > 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.
libgii and libggi have some rpm spec files in the dist/rpm subdirectory. For all libs, we need to create them. I think, it is a good idea to give Martin Albert CVS write access, so that he can manage his debian package files in the dist/debian subdirectory of each lib. I don't know, if this makes his life easier for him, but when we really go to create rpm specs from .debs, then we definitely need the debian package files. > > 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. hmm... far too less 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". What we need is something other do NOT have. libggigl and XGGI are a good examples. See Brian's mail and my next one for more details. > Christoph pointed me to the IRC logs today. I didn't even know they > existed! The URL I gave you is mention on http://www.ggi-project.org/contact.html > 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 ... 7. Make the GGI website looking more professional. People should not think "Oh no, not yet another graphic lib". The site should give people more indepth clearness and transparency on GGI's design, how things relate together... Using UML datagrams and such things should be used. On my uni, there are some professors searching for good designed software for teaching purpose!!!! I already point some, but they still can't do that, because design relations, dependencies and even goals and other things are too ... "opaque" to understand. 8. Upon point 7), the site should clearify, _where_ the projects stand, what needs to be done and lots of tutorials, guides, etc. New people think to first read huge amount of docs and need deep indepth understanding before being able to provide some patches... -- 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!
