Re: Proposal to deprecate Xlib backend

[Richard Frith-Macdonald]

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?