On Wed, 13 Dec 2000, John McCutchan wrote:
> On Tue, Dec 12, 2000 at 10:23:12PM -0500, Stefan Seefeld wrote:
> > Christoph Egger wrote:
> >
> > > [22:17] <macarena> Personal goals: 1. Make a release. 2. Find a few
> > > people doing maintenance stuff.
> > > [22:18] <macarena> 3. Find a few people that want to seriously take
> > > LibGGI2D and -3D or GGIMesa ...
> > >
> > > How about removing the current LibGGI2D from cvs and renaming libxmi
> > > to libggi2d?
> >
> > this is a political decision. There are quite a number of 2d libraries,
> > wasn't there even report of a libart based extension ? 'ggi2d' suggests
> > that it is the one and only (official) 2d library for GGI. that might
> > just not be true. (At least right now it is not true for ggi2d nor for
> > ggi3d, and it wouldn't be true for any other 2d/3d library).
> > To reiterate (and I think this is really important as a message to other
> > people), I'd strongly suggest GGI to concentrate on the 'generic' part,
> > and provide extension mechanisms to provide accelerated higher level
> > libraries, without mandating any 'official' one. If nothing else, that
> > will help keeping (or getting back, however you see it) GGI on scope.
> >
>
> I completly agree. When ggi makes its official release the tree should
> be cleaned of everthing but gii and ggi. Everything else is half-finished
> and not working entirely, Its very important that people see that ggi
> isn't dead and I don't think releasing an official release that has more
> broken libraries then working ones is a mistake. I think Stefan is right
> when he says that GGI needs to concentrate on providing a generic interface
> that supports hardware acceleration through KGI. Everything else should
> not be an official part of GGI. Perhaps add a section to the website
> that contains projects such as libggi2d, etc. but in order to look
> professional we can't have a bunch of half-working libraries which would
> just distract people from ggi itself.
>
I agree too. But how would you develop a higher-level lib without
bloating it with lower-level-stuff?
At first the lower-level ones have to be _finished_ and well
done. Even the ones, which doesn't exist yet.
LibXMI for example is a half-working one, because of some bugs
(for example: ggiSetMode() doesn't work, _after_ xmiAttach() is
called) and the software-rasterizer needs a _completly_ new rewrite
to do it well.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
