Re: Proposal to deprecate Xlib backend
On 12/28/06, Hubert Chan <[EMAIL PROTECTED]> wrote: On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). I think people are talking about using X11 for drawing, not window and even handling in this case. So deprecating x11 backend does not affect the use of X11. Yen-Ju -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Hi! On Mon, Dec 25, 2006 at 06:00:59PM +, Richard Frith-Macdonald wrote: > 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 understand your concern that Cairo is not ready yet for production use. But isn't art stable enough? I haven't heard of people using or even promoting the use of xlib in a long time. > 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). As a voluntary open source developer, I personally usually prefer implicitly understandable hints about how to write code over big developer documentation. Time is limited after all, and when programming in one's free time, people want to get to the nitty gritty fast. :-> For example, it's obvious that you shouldn't spend a lot of time on code which is located in a directory called 'deprecated'. But has everybody outside the GNUstep core team read the GNUstep developer documentation? I could also imagine that a clear indication that xlib is deprecated may help people outside the GNUstep project. For example when looking at Etoile, there are at least the MultimediaKit and the XWindowServerKit which directly talk to X11 (MMKit displays the Mplayer window in a GNUstep window). For authors of projects like these two, it may be very helpful to know that they won't have to support xlib in the future. But those are just my 2 cents. :-> -Guenther ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 12/26/06, Fred Kiefer <[EMAIL PROTECTED]> wrote: Yen-Ju Chen schrieb: > I guess this is the reason why transparency does not work in Cairo > backend: > cairo backend draw everything directly on xwindow. > In -gui, an image is often draw on a hidden window, then composite > on the destination. > Because cairo backend draw directly on xwindow first, > it loses the alpha value. > Then when it is composited to the destination, > the transparent part becomes the background of the hidden window. > > I have a copy of cairo backend in Etoile project: > http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ > It basically draw on the x11/XWindowBuffer first as what art backend does. > Therefore, it keeps the alpha value for composition. > The modification is very little. > You can check out README.etoile_back. > A simple diff is sufficient to see the difference of source code. > There are some minor issues here and there, though. > Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. Don't bother with the x11 part. It is just for some experimental stuffs. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in "pkg-config --libs cairo" at a command prompt to see if this includes freetype or not? I have problem with linking to freetype2 before. I will try it again. I also added you endianess change, hope I did get it correct. I am not sure I did this one right because sometimes I see weird colors here and there. Again, it is just some experiments I were working on. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. The unbuffered stuff is from art backend. But frankly, I don't really understand the difference between the non-retained, retained and buffered window. So, just ignore it for now. You can treat the NSClipView category as a not-so-elegant implementation. GNUstep-gui try to save time by copy old area to new position. For a not-so-good implementation, it probably just ask backend to draw everything again. And it is what this category does. :) Yen-Ju With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Yen-Ju Chen schrieb: > I guess this is the reason why transparency does not work in Cairo > backend: > cairo backend draw everything directly on xwindow. > In -gui, an image is often draw on a hidden window, then composite > on the destination. > Because cairo backend draw directly on xwindow first, > it loses the alpha value. > Then when it is composited to the destination, > the transparent part becomes the background of the hidden window. > > I have a copy of cairo backend in Etoile project: > http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ > It basically draw on the x11/XWindowBuffer first as what art backend does. > Therefore, it keeps the alpha value for composition. > The modification is very little. > You can check out README.etoile_back. > A simple diff is sufficient to see the difference of source code. > There are some minor issues here and there, though. > Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in "pkg-config --libs cairo" at a command prompt to see if this includes freetype or not? I also added you endianess change, hope I did get it correct. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
[EMAIL PROTECTED] wrote: 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. I think the less backends the better, as its less code to maintain. That said, the cairo backend should function correctly out of the box i.e. there should be any need to go fishing around for anything other than cairo and cairo-glitz on the Internet. I believe this is already the case. Also, whilst we're on the topic of backends, is it worth trying to formalise and clean up the backend API? I don't know how other people feel about this, but to me it seems to be in want of some cleaning up e.g. set standards on the API instead of a mixture of old DPS commands and methods from various classes used to define the backend. Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 12/25/06, Fred Kiefer <[EMAIL PROTECTED]> wrote: Gregory John Casamento schrieb: > Richard, > > The reasons behind the move to Cairo are as follows: > > 1) Cairo is being used by a number of other projects. It is very stable and well maintained. > 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. > > I agree with what Richard is saying here as well. > Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Happy holidays. Yen-Ju There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
It's done then... Both XLIB and ART will be deprecated in the near future. We are shifting focus onto the Cairo backend. Development efforts on the backend should concentrate on getting the Cairo backend up and running. Once this is done XLIB and ART backends will stay in the repo for a TBD amount of time after which they will be moved to the obsolete folder. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> Cc: Richard Frith-Macdonald <[EMAIL PROTECTED]>; GNUstep Developers Sent: Monday, December 25, 2006 5:57:04 PM Subject: Re: Proposal to deprecate Xlib backend Gregory John Casamento schrieb: > Richard, > > The reasons behind the move to Cairo are as follows: > > 1) Cairo is being used by a number of other projects. It is very stable and > well maintained. > 2) Cairo has been ported to a number of other operating systems, including > windows and has a large number of output targets. This way, Cairo would do > much of the heavy lifting for us with regards to getting things to render > acceptably on other platforms. > > I agree with what Richard is saying here as well. > Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Gregory John Casamento schrieb: > Richard, > > The reasons behind the move to Cairo are as follows: > > 1) Cairo is being used by a number of other projects. It is very stable and > well maintained. > 2) Cairo has been ported to a number of other operating systems, including > windows and has a large number of output targets. This way, Cairo would do > much of the heavy lifting for us with regards to getting things to render > acceptably on other platforms. > > I agree with what Richard is saying here as well. > Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> Cc: GNUstep Developers Sent: Monday, December 25, 2006 1:00:59 PM Subject: Re: Proposal to deprecate Xlib backend 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
Re: Proposal to deprecate Xlib backend
--- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > > 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? > I basically agree with everything Richard said here, though i wanted to chime in that there is a backend for cairo on directfb, (speaking backend for cairo not GNUstep backend for cairo, if that makes any sense) so we'd just need to write all the directfb event handling and stuff, to get a usable directfb system it seems directfb lacked alot of the postscript drawing primitives until the cairo port so this should seriously cut down on the amount of work involved, this has been on my mind for about a week or so, haven't gotten the gumption to actually try the cairo backend, or code anything... __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
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
