On Tue, 29 Aug 2000, Stefan Seefeld wrote:
> Andreas Beck wrote:
>
> > Yeah, I know - all that sounds pretty pessimistic. And I always feel pretty
> > sad, when it comes to that topic. GGI is "my baby" more than any other open
> > source project. And there is quite some blood, sweat and tears I and several
> > other people put into it, so it really hurts to see it fall in decay. I'm
> > pretty busy these days juggling two jobs, so I don't have so much time left
> > to work on GGI. While this is bad for GGI, it helps a little to distract me
> > from my "broken heart" about the project's state.
> >
> > But maybe some folks here would like to cheer me up a little ?
>
> hey Andreas, we need GGI !! :)
>
> Well, having said that, I have to weaken it already. I worked on the Console
> abstraction for berlin this summer and we are now in a position where we can
> implement it not only by GGI, but SDL, GLUT, cavelib (to see what the later is
> good for, it drives this device:
> http://www.medialab.chalmers.se/cube/CubeInfo/description.html
>
> So in short, berlin doesn't *depend* on GGI (or any other specific console
> access library) any more. However, we'd really appreciate further work on
> GGI ! We'v well realized that GGI was a bit neglected recently. And one of
> the reasons I see and suspect is the lack of focus. Consider berlin: although
> we are still in early development, we advance at a healthy pace, which is (among
> others) due to the fact that at least the standard features of a windowing system
> and desktop environment are well known, so we know the spots to work on.
In other words, GGI needs a clear raison d'etre. We need
'customers' with requirements we can't currently meet. Berlin is one of
the best of our current 'customers', but there are others.
> in GGI on the other hand, I see lots of little effords here and there, a very high
> number of new sub projects, which are unfortunately almost never driven to some
> final point of usability (for other than the developers themselfs).
Most of these subprojects are designed to either plug a specific
hole (like LibXMI, which I was paid to write), or they are more
experimental or proof-of-concept (LibGGI3D, LibGWT, LibGFFD, etc).
> The lack of releases is a good indicator. Just to name a few: GGI2D, GGI3D, XMI,
>MesaGGI.
> I name these because they could be very interesting for berlin, yet none seems in a
>state
> where it makes sense for us to found other software on it (we use pluggable
>renderers which
> implement the 'DrawingKit' interface. We currently have two, one for MesaGGI, the
>other
> for libart on GGI, but Jon told us that MesaGGI wasn't maintained any more...).
It isn't _DEAD_, just hibernating. I keep asking for someone with
a bit more free time to volunteer as the GGIMesa maintainer, but no one
has bitten yet. It won't necessarily have to involve much nasty icky
confusing GGI internals work (yes, that was sarcasm), just fixing simple
bugs and keeping the API in sync with Mesa in general. I'll be more than
happy to help anyone who wants to volunteer, I just can't take on such a
time-consuming task right now.
Also, there is 'LibGGI-GL', which Marcus mentioned a few months
back. This would provide an OpenGL-to-GGI binding, much like what GGIMesa
does now, but it would not attempt to implement a GGI-style 'direct'
target architecture wherein the target code itself made the low-level
rendering calls. Instead, it would implement 'indirect' GL rendering by
encapsulating preexisting GL implementations (XMesa, GLX, WGL on Win32,
AGL on Macs, etc etc) into "wrapper targets". This would be about a
million times easier to code than GGIMesa and could provide a nice way to
fix Berlin's problem of reliance on GGIMesa.
> > What GGI needs is a driving force. Look at the mailing list. It's quiet.
> > Really quiet. The only postings are a few newbies seeking help or asking for
> > features, and from time to time, me, Marcus or a few others that annouce
> > a little new feature they coded up, because _they_ needed it.
>
> precisely. I do think that the basic ideas behind the GGI project are still valid.
> Yet lots of people wonder when I mention GGI, whether the project is still alive
> at all.
>
> If you don't find the time to work yourself on it, may be you could try to give the
> project some more structure (in terms of project management), a task/request list
> for example, and act merely as a coordinator/mentor. I'm sure people will help if
> they see that GGI is still actively worked on.
We could start mailing CVS commit notifications to either the
existing ggi-develop list or a new ggi-cvs-announce type of list. Many
OSS projects now do just this. I implemented such a feature for the
mailing lists hosted at opensource.creative.com, and it is quite
remarkable how much more interested in the project even _I_ was when I
checked the mailing list and saw one or more new 'cvs:jtaylor' mails. It
really does help to keep people's interest up, it keeps them looking at
the CVS repository, it stimulates technical discussions, etc etc.
Another idea is to host a Bugzilla database on www.ggi-project.org, if
Metalab UNC will allow it. Bugs, To-do list items, feature requests, etc
can all be accomodated by this one tool!
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
