On 25 Dec 2006, at 14:59, Gregory John Casamento wrote:
All,
I've been thinking about deprecating the Xlib backend, so that we
can focus more on Cairo. I have discussed this with Fred and I
would like to know what everone else thinks about it.
Depends what is meant by 'deprecate'.
It seems reasonable to move away from it ... but Cairo is not ready
yet, and the art backend seems to have its own problems. My
impression is that art is a little better than xlib but harder to
maintain (code less clear etc). I'm taking it on trust (Fred's
judgment and yours) that Cairo is the way to go rather than improving
an older backend ... I don't have the graphics knowhow to make a good
judgment myself.
I think very little time is spent on maintaining either art or
xlib ... interaction with x window managers needing (and getting)
more attention than the actual xlib or art rendering code, so it's
not a big issue right now.
However, we do need to make sure people don't waste time on
development work for multiple backends ... so we need a clear policy
for future development work (especially for any new volunteers).
So, in terms of what people should be told to *use*, I don't think
we should deprecate xlib until Cairo is more usable than it, but in
terms of what people should do development work on, I would deprecate
both xlib and art immediately. Once cairo is at least as usable
(glitch-free, feature-full, and quick) as xlib and art, we should
deprecate both old backends. I think backend development work should
concentrate on cairo. If Cairo also works well in the mswindows
world, we should probably concentrate on a cairo graphics engine for
both unix and windows. For MacOS-X compatibility, would it be
possible to do CoreGraphics in terms of Cairo for both unix and windows?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev