Uploaded: libggigcp*.d{sc,eb}, libggiwmh*.d{sc,eb}
Hello, All! Uploaded files with names similar as given in Subject:. As these are new packages, it may take a while until they go to the archive. Until then you may use http://incoming.debian.org. Ok , i'm away now until weekend. Have fun! martin
Re: World-Domination - was Re: multi threaded... Details: Names
On Wed, 18 Dec 2002, Andreas Beck wrote: > Rodolphe Ortalo <[EMAIL PROTECTED]> wrote: > > > 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). Yes! These are exactly my dreams for the (near) future of libggi. 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. 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. Just imagine the results: we'd get all that the dri project has accomplished and more! The XGGI server merely hooks its clipping information to a subvisual on which you can fire up a ggiMesa app, and you get effortless OpenGL with direct rendering (note that I'm not suggesting that this subvisual be used for all X windows as the current implementation for this functionality in X is probably more efficient for the common case). Not only that, but these pieces would be windowing system independed so Fresco (or any other windowing system) would get direct rendering as well. This is what I think is important at the moment. A flexible subvisual along with ggiMesa and XGGI would give us all that XFree86 has with a beautiful design (nearly all actually, Xv would still be missing). Accomplishing this would certainly give the ggi project much more visibility and attract many users and developers. Finally, I have to admit that, as a KGI developer, lot of these ideas are focused on libggi running on top of KGI. On the other hand, lot of the current development effort is focused on generic resource management which really makes sense only on KGI (and fbdev) which leads me to believe that libggi on top of KGI is important in the eyes of ggi developers. -Filip
Re: libggigic
> libggigic is a GGI library (no extension) on top of libgii - not libggi! > Now, I am glad to tell you, that I just got it working on Darwin/MacOSX. > libggigic is in the ggi-libs CVS module. > Anyone to try out (on different platforms) ? Needs a time.h on Linux in one of the demos I think. And could do with a better demo :-). The snazzymanager is nice, but the ggidemo is quite lame (I may say that I coded it :-). 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!
libggigic
Hi! For those, who don't know, what libggigic is: libggigic is a GGI library (no extension) on top of libgii - not libggi! It allows GGI applications to bind actions with input events at runtime. You probably know this feature from many games, where you can change the fire button at runtime. Now, I am glad to tell you, that I just got it working on Darwin/MacOSX. libggigic is in the ggi-libs CVS module. Anyone to try out (on different platforms) ? -- 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: 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
On Tuesday 17 December 2002 20:25, Martin Albert wrote: > > Heh! Where do you get this messages from? > Huh? This my own! [Explicit On] Hanging out on dubious hacker websites, like ggi-project.org and such, following links to stuff that interests me, i often end up downloading from stacken.kth.se, strange favicon, strange mackan@ ... :-) Eg., svgalib4libggi, ggi driver for 1.2 synaesthesia, lcd821(?). 'Hey, Marcus' was short for: In my free time i like to try to update and improve / fledge out these well written pieces of code. I'm always interested in udpates, have some myself, when they are so far, i will send them to you, ok? I understand that you mostly work on sth. else and so think that no further explicit 'locking' of the source code is necessary to avoid duplication of efforts. As for svgalib4libggi, i did not yet apply officially for ggi maintainership, but am very interested and busily hacking on it. Plan is to make it a functional replacement for svgalib while at the same time it should be easy to have them both installed on the same machine and decide as late as possible which one to use. More on that with the beginning of the new year. [Explicit Off] martin :-)
Re: Unsupported platform?
> On Tue, Dec 17, 2002 at 10:45:38PM +0100, Nicolas Souchu wrote: > > Hi, > > > > plat.h from CVS of 12/12/02 says my FreeBSD box is unsupported. Is that > true? > > Here is a patch to libgii/gg/plat.h > > Index: plat.h > === > RCS file: /cvsroot/ggi/ggi-core/libgii/gg/plat.h,v > retrieving revision 1.10 > diff -u -r1.10 plat.h > --- plat.h 2 Nov 2002 13:18:29 - 1.10 > +++ plat.h 17 Dec 2002 22:24:08 - > @@ -53,7 +53,7 @@ > > #ifndef _POSIX_SOURCE > /* *BSD system */ > -# if defined(__OpenBSD__) || defined(__NetBSD__) > +# if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__) > # define _POSIX_SOURCE > # endif TNX. It's committed now. > Is the following armless? > > armor:/usr/devel/ggi/ggi-core/libgii# ./autogen.sh > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > WARNING: and `config.h.top', to define templates for `config.h.in' > WARNING: is deprecated and discouraged. > > WARNING: Using the third argument of `AC_DEFINE' and > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > WARNING: `acconfig.h': > > WARNING: AC_DEFINE([NEED_MAIN], 1, > WARNING: [Define if a function `main' is needed.]) > > WARNING: More sophisticated templates can also be produced, see the > WARNING: documentation. > autoheader: `config.h.in' is unchanged > automake: reading configure.in > automake: reading aclocal.m4 > automake: reading Makefile.am > automake: creating Makefile.in > automake: reading gg/Makefile.am > automake: creating gg/Makefile.in > automake: reading gii/Makefile.am > automake: creating gii/Makefile.in > [...] > > Thanks. Yes. I get this under Solaris 8, too. I use autoconf 2.54 and automake 1.7.1 there. The warning says only, that we should go away using acconfig.h files in the (near) future. -- 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: Unsupported platform?
On Tue, Dec 17, 2002 at 10:45:38PM +0100, Nicolas Souchu wrote: > Hi, > > plat.h from CVS of 12/12/02 says my FreeBSD box is unsupported. Is that true? Here is a patch to libgii/gg/plat.h Index: plat.h === RCS file: /cvsroot/ggi/ggi-core/libgii/gg/plat.h,v retrieving revision 1.10 diff -u -r1.10 plat.h --- plat.h 2 Nov 2002 13:18:29 - 1.10 +++ plat.h 17 Dec 2002 22:24:08 - @@ -53,7 +53,7 @@ #ifndef _POSIX_SOURCE /* *BSD system */ -# if defined(__OpenBSD__) || defined(__NetBSD__) +# if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__) # define _POSIX_SOURCE # endif Is the following armless? armor:/usr/devel/ggi/ggi-core/libgii# ./autogen.sh WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `config.h.in' is unchanged automake: reading configure.in automake: reading aclocal.m4 automake: reading Makefile.am automake: creating Makefile.in automake: reading gg/Makefile.am automake: creating gg/Makefile.in automake: reading gii/Makefile.am automake: creating gii/Makefile.in [...] Thanks. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
Re: Unsupported platform?
> Hi, > > plat.h from CVS of 12/12/02 says my FreeBSD box is unsupported. Is that > true? No, that's an issue in plat.h. Please look into it. FreeBSD obviously does NOT define _POSIX_SOURCE. Please add the most proper posix #define of FreeBSD. -- 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: Synchro between accelerator and fb-based drawing
On Sun, 15 Dec 2002, Brian S. Julin wrote: [...] > A sublib that has the need for idling the accelerator should provide > at least hline, vline, box; e.g. it should not leave solid-fill > primitives to the generic renderers, because the generic libs only > contain "accelerator aware" versions of the single-pixel functions. Is it also the case for putc, puts (and possibly copybox)? I have some strange output with them. I also have some strange things around clipping. It seems I need to call GGI_kgi_Gx00_idleaccel() myself from my GGI_kgi_Gx00_gcchanged() function as soon as some clipping modifications are involved. If I don't, some of the output of "./demo" is incorrect wrt hline, vline of box tests. Rodolphe
Unsupported platform?
Hi, plat.h from CVS of 12/12/02 says my FreeBSD box is unsupported. Is that true? Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
Re: World-Domination - was Re: multi threaded... Details: Names
On Tue, 17 Dec 2002, Andreas Beck wrote: > 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. You are too negative. What about 2 independent applications sharing a single 3D engine? What about doing more complex scenes? You know, whatever the advance of PowerPC, MacOS9 was doomed... IMHO, the difficulty with GGI or KGI is more the lack of documentation and support for graphics hardware (as ever) than something else. > 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. Which widget library? Some of your own or something more general? BTW, what about Berlin/Fresco? Rodolphe
[ANNOUNCE] LibGGIMisc 2.0.2 is out
Hi! I don't wanna libggimisc hold back no longer due to the not yet updated X-target. Check out http://www.ggi-project.org/libggimisc.html for ReleaseNotes and download links. -- 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: 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
> 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. Heh! Where do you get this messages from? -- 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: LibGGI install issues
CBS already decided to install the demos with ggi- prefix in Debian. I keep this up, you just have to type ggi- and see all demos and other binaries to choose from. I didn't install cpuinfo yet, when you don't either it's ok. The existence of this functionality is recorded in debian.changelog. I might also add it to the readme. The sources are installed to /usr/share/doc/libggi0/examples anyway. martin
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: LibGGI install issues
On Tue, 17 Dec 2002, Andreas Beck wrote: > GII installs a binary called "cpuinfo" - that's too generic. Either > don't install it, or call it giicpuinfo oder ggicpuinfo or something. > I am not aware of an application that uses this name now, but I think > I can imagine apps where the name fits much better. There's really no reason to be installing that "demo", it's only there for internal testing purposes. -- Brian
Re: LibGGI install issues
> Hi folks, > > I just tested LibGGI installation into a private path (/tmp/eccet) > and found a few annoying things we should fix: > > GII installs a binary called "cpuinfo" - that's too generic. Either > don't install it, or call it giicpuinfo oder ggicpuinfo or something. > I am not aware of an application that uses this name now, but I think > I can imagine apps where the name fits much better. Fixed in CVS. I changed libgii/demos/Makefile.am, so that cpuinfo no longer get installed. > GII installs a man section "mana" containing a Makefile. Strange. > > I'm not quite sure if GGI also does this - something to check out. Eric? -- 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!
LibGGI install issues
Hi folks, I just tested LibGGI installation into a private path (/tmp/eccet) and found a few annoying things we should fix: GII installs a binary called "cpuinfo" - that's too generic. Either don't install it, or call it giicpuinfo oder ggicpuinfo or something. I am not aware of an application that uses this name now, but I think I can imagine apps where the name fits much better. GII installs a man section "mana" containing a Makefile. Strange. I'm not quite sure if GGI also does this - something to check out. CU, Andy -- Andreas Beck | Email : <[EMAIL PROTECTED]>
Re: libggigl
> > > The problem is LINKING! > > Is it? Why not solve it in the same way LibGGI and its extension solve it? > > Just dynamically load a renderer lib and link that one to the lib in > > question. > That was my first thought too. However, there's a catch; If you link the > sublib with the appropriate GL library when you go to link your program > with libggigl all of the opengl symbols are missing! Well yes, but that isn't much of a problem. I am using something similar in a module system that will use externally provided functions. You can ask the linker to shut up and link on runtime only. Ugly but works. It has some drawbacks, though, as it will mask any other functions youz have not provided, thus leading to ugly runtime errors. Another method would be to provide stubs that get redirected internally. Quite some task for a large API like OpenGL. CU, Andy -- Andreas Beck | Email : <[EMAIL PROTECTED]>
Re: libggigl
Hi, On Tue, 17 Dec 2002, Andreas Beck wrote: > > The problem is LINKING! > > Is it? Why not solve it in the same way LibGGI and its extension solve it? > > Just dynamically load a renderer lib and link that one to the lib in > question. > That was my first thought too. However, there's a catch; If you link the sublib with the appropriate GL library when you go to link your program with libggigl all of the opengl symbols are missing! You should be able to simply export whatever display you want and let libggigl worry about what GL implemenation to use. This is why you don't want to just 'gcc -o foo foo.c -lggigl -lGL' either. Paul > LibGGI itself doesn't depend on X either, but the x target does. > > > CU, ANdy > > -- > = Andreas Beck| Email : <[EMAIL PROTECTED]> = >
Re: libggigl
> The problem is LINKING! Is it? Why not solve it in the same way LibGGI and its extension solve it? Just dynamically load a renderer lib and link that one to the lib in question. LibGGI itself doesn't depend on X either, but the x target does. CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: World-Domination
Hi Jos,
On Tue, 17 Dec 2002, Jos Hulzink wrote:
> On Tue, 17 Dec 2002, Christoph Egger wrote:
>
> > 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.
>
> What you need is what you got __finished__. The focus should not be on
> creating new things, but on finishing what there is. The KGI target is for
> both GGI and KGI a very important thing, but it doesn't work. (Major
> issue: the KGI target simply ignores the existence of devfs). Some work
I hacked in the device parameter to the kgi target without much thought.
I would appreciate any opinions on how the target should work in practice.
I have not tried graphic on a kgi kernel with devfs but I assume it
enumerates a /dev/graphic{0..} for each device? If so, how should the ggi
target decide which device to run on?
Paul
> has been done on the GGIGL stuff, but it was never finished.
>
> Features are nice, but only when the foundation is rock solid.
>
> Jos
>
Re: World-Domination
On Tue, 17 Dec 2002, Christoph Egger wrote: > 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. What you need is what you got __finished__. The focus should not be on creating new things, but on finishing what there is. The KGI target is for both GGI and KGI a very important thing, but it doesn't work. (Major issue: the KGI target simply ignores the existence of devfs). Some work has been done on the GGIGL stuff, but it was never finished. Features are nice, but only when the foundation is rock solid. Jos
libggigl
Hi! libggigl an extension to allow users _any_ opengl implementation and not necessarily GGIMesa. libggigl has been discussed on IRC. It should only have targets with native opengl implementations (i.e. X with GLX, DirectX with wgl). A stub target should be there representating all other targets with NO native OGL implementation such as kgi, aa, etc. Those should run upon GGIMesa. We would quickly have something others do NOT have: Running OpenGL applications on various environments (even HW acceleratered!), switching targets on the fly, etc. So far, things look simple and simple doable. But it is NOT. The problem is LINKING! It must be possible to only and only link GGIGL applications against libggigl. Linking against any certain opengl implementation adds the dependence, they do not have to have in order to provide the above mentioned features. But if you don't, many symbols can't be solved by the linker. The major point is, _which_ ogl implementation should be linked against, when there are more than one ogl implementation on one platform? That situation is actually not rare: Mesa and GLX on Linux, GLX, WGL and Mesa under Win32, GLX and MacOSX under MacOSX, etc. For the linking issue, there has still been found no solution. Ideas, comments, etc... everything is appreciated. -- 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: World-Domination
> > 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. (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
