Re: ggv/gpdf and evince
Il giorno gio, 09/06/2005 alle 13.08 -0400, Luis Villa ha scritto: I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Wait. There are some troubles with poppler+cairo on head :-( I didn't yet report them, 'cause I'm still performing some tests and collecting info on not well behaving PDF files, but it seems there is a performance regression in recent CVS builds. The most critical PDF file is this[1] introduction to signal processing in Scilab (and maybe all PDFs from the same location): it locks the poppler benckmark application at page 2 (!!!) and leaves the evince view empty. There are some slowness with some PDFs[2] from Apple website[3] too. I _suppose_ it could be a cairo issue, because I remember that all works fine in pre cairo-0.5.0 days. BTW it seems that gpdf too has a wrong rendering on [1]: all math formulas disappear (see i.e. page 16 or 19) and some graphs are simply wrong (see i.e. page 18): only xpdf (3.00) works fine in this file :-| And evince+poppler_splash of course. Moreover it seems that evince suffers for a slow re-rendering on resize that you can't feel in gpdf. With and without poppler's cairo output. Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As attachment there are my records about poppler benchmarks: I'll report them on poppler bugzilla. [1] ftp://ftp.inria.fr/INRIA/Scilab/documentation/pdf/signal.pdf [2] http://images.apple.com/server/pdfs/Workgroup_Manager_TB_v10.4.pdf [4] http://www.apple.com/server/resources/ Poppler Benchmarks Poppler 0.3.2 (cairo 0.5.0) Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |48.38 |21.43 |20.43 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |137.46 |71.07 |57.39 | - Time Out|161|1.3MB |6.36 |3.81 |1.48 | - 101 GNOME things|90 |1.8MB |58.53 |47.36 |1.82 | - OSX Workgroup Manager |6 |316KB |1.51 |0.77 |0.24 | Poppler HEAD (cairo HEAD) on 2005-06-07 Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |45.65 |22.66 |19.81 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |* |* |* | - Time Out|161|1.3MB |6.27 |4.10 |1.49 | - 101 GNOME things|90 |1.8MB |58.02 |53.46 |1.80 | - OSX Workgroup Manager |6 |316KB |7.84 |7.05 |0.32 | Poppler HEAD (only Splash) on 2005-06-07 Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |66.05 |42.14 |20.01 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |20.11 |10.78 |7.95 | - Time Out|161|1.3MB |16.70 |14.07 |1.56 | - 101 GNOME things|90 |1.8MB |13.10 |11.06 |1.15 | - OSX Workgroup Manager |6 |316KB |1.54 |0.61 |0.23 | * Still rendering page 2 after about 3 minutes :-((( Killed. top says: PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 25 0 225m 190m 7608 R 84.1 76.2 2:59.87 benchmark Some info and notes about test suite * PLRM PDF version 1.1 A complex document, but well written: Evince don't
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? Regards, Jeroen On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: With the Mist theme, you are testing mixed Cairo and GDK rendering. Right now, that could conceivably hide some performance problems with Cairo. In the future, there are some performance optimizations that will be disabled when you are mixing Cairo and GDK rendering. The GTK+ builtin theme probably gives more of an accurate feel for GTK+/Cairo performance. What the appropriate theme to test is does depend on what we will be shipping for GNOME-2.10 as the default, of course. Which is likely not the GTK+ builtin theme. GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 Without studying what these benchmarks are actually doing, I'd consider them pretty encouraging ... some operations got faster, and what got slower is something we have in our sights already ... cairo_scaled_font_glyph_extents(). (GtkTextView performance is text measuring performance.) There is an obvious big-hammer approach that would allow us to get rid of that ... to put a cache in front of it so that we avoid calling into Cairo entirely, but I'd like to see what we can do inside of Cairo first. Regards, Owen BodyID:12373415.2.n.logpart (stored separately) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:21 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) I didn't know you could even use glitz with gtk+ HEAD? I asked owen, and he didn't think it worked atm. How did you run this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a suicidal drug-addicted ex-con fleeing from a secret government programme. She's a sarcastic insomniac mechanic trying to make a difference in a man's world. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 14:47 +0100, Mark McLoughlin wrote: On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: - To be realistic, if GNOME-2.12 is released after GTK+-2.8, most distributors are going to ship using them together. So, the release team could decide to go with 2.6 even with the current GTK+ schedule, but the result then would be less testing of what people actually ship. Yeah, and that would significantly undermine the whole release process IMHO. If the value of having GNOME releases is to have the very latest GNOME technologies released as a stable, coherent and integrated set, then by creating a situation where distributors go off for themselves and figure out what *really* is the latest stable set of GNOME technologies, we really reduce the relevance of GNOME releases. Well there are GNOME hackers working at all the major distributors who I am sure are able to inform the rest of their organization that going with GTK 2.8 would greatly increase the risk of bug and problems since it is not what the community have developed and tested with. If we believe that we can't influence the distributions on what they ship anyway, then maybe our whole release process is to be considered useless. I mean what is the point of doing GNOME releases if we assume nobody cares about how we compose our releases anyway. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote: On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) I suspect that it's just difficulties in the benchmark ... especially with GtkTextView, things can happen a little differently each time you run it ... a different balance between repainting the screen and updating the text. Everything other than GtkTextView looked the same up to noise, but the GtkTextView numbers dominate the total. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
[Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Mark McLoughlin [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: - To be realistic, if GNOME-2.12 is released after GTK+-2.8, most distributors are going to ship using them together. So, the release team could decide to go with 2.6 even with the current GTK+ schedule, but the result then would be less testing of what people actually ship. Yeah, and that would significantly undermine the whole release process IMHO. If the value of having GNOME releases is to have the very latest GNOME technologies released as a stable, coherent and integrated set, then by creating a situation where distributors go off for themselves and figure out what *really* is the latest stable set of GNOME technologies, we really reduce the relevance of GNOME releases. I'm all in favor of getting 2.7 tested and released, and I think we should push hard to test it with 2.11. That'll obviously help it get better, and fast. But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. Luis *except JDS ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote: [Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) Luis I have patches for all core GNOME modules and if they aren't already in CVS it means they were just not applied yet. If anyone else needs help porting their stuff just let me know. I need to make a new DBus release pretty soon. I will do so before I go to Germany next week. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On 6/10/05, John (J5) Palmieri [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote: [Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) I have patches for all core GNOME modules and if they aren't already in CVS it means they were just not applied yet. Are they in bugzilla? :) If anyone else needs help porting their stuff just let me know. I need to make a new DBus release pretty soon. I will do so before I go to Germany next week. OK, that settles that. 0.3x it is. Luis (executively deciding ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On Fri, 2005-06-10 at 10:33 -0400, Luis Villa wrote: On 6/10/05, John (J5) Palmieri [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote: [Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) I have patches for all core GNOME modules and if they aren't already in CVS it means they were just not applied yet. Are they in bugzilla? :) So I thought I got most everything in but may have forgotten to commit a few (or the maintainer never replied during my patch rampage, etc). If we can get a list of modules that have yet to be ported I can attach the patches to bugzilla. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. My point there is not that I expect 2.8.0 to be buggy, but basically that when mclasen is deciding on what version of GTK+ to go into a Red Hat product, or when federico is figuring out the same thing for Novell, there's going to be a lot more information and factors available to them then to the release team several months previously. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
Hi Federico, Last Wednesday at 21:02, Federico Mena Quintero wrote: It would be great if you could start a checklist in live.gnome.org of particular APIs which are widely used and upon which people need to set up things like gettext domains. I could certainly use this for the Gnome certification thingy here :) http://live.gnome.org/GnomeCertification I added a couple of pointers to: http://live.gnome.org/GnomeI18nDeveloperTips Not sure if that helps. Oh, now that I think of it, when we're talking about Gnome Certification, we should also probably mention .desktop files, .schemas, etc even though it's mostly covered in Malcolm's i18n guide listed second under Documentation there. Note that I don't know the APIs too well, and some of the online API references seems to be pretty outdated (like libglade one I found through Google). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, As an aside, when I say 'stable', I mean 'reliable for users', not 'API stable for developers', and maybe that is part of the confusion of this thread. I expect GNOME .0s to be both stable (in your sense) and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not reliable in mine, and that is why release team is wary of telling people that a gnome .0 based on gtk 2.8.0 would be reliable. but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. I'm not claiming we do or should. You get to release .0 whenever you want, and users get to use it whenever they want. Release-team gets to say when they think it is reliable, and hence worthy of being part of GNOME. Ideally your .0 and our .0 should have the same qualities, but in our past experience they have not. This whole conversation is unfortunately sounding very hostile, which was not my intent. Let me try to back it down a little bit and get it back to the first principles, explain why (IMHO) gtk 2.4.0 was not reliable enough for GNOME 2.6.0, and see if/where/when we can compromise from those. With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full three months before GNOME 2.10 was, allowing for extensive testing and several GTK point releases. Avoiding a repeat of this very difficult problem is my primary concern. GNOME generally avoids this with three big strategies: * avoid entanglements and only release things that are ready: we look at apps case by case and if necessary reject them if they aren't ready on our timeline[1]. This only works if the apps do not provide API to other parts of GNOME, or if their API has not changed. Unfortunately, this can't be the case for GTK- we must be entangled for good testing to happen, so we can't just get to september and say 'gtk isn't ready, punt it.' This means that if we choose to go with gtk 2.8.x, 2.8.x *must* be rock-solid stable at the GNOME 2.12.0 date, we have to punt apps that have upgraded their deps to 2.8.x, or we have to slip. (Or we can ship a .0 we're not happy with, but I'd like to think that isn't an option.) * aggressive freeze schedules: we freeze early, and ask for early releases. As has been pointed out, this does reduce features in favor of stability. * extensive testing: while we've been doing a poorer job of this than we used to, we still rely heavily on extensive testing of unstable releases to make our .0 releases as stable as possible. Because people are nervous about testing gtk, we know it gets less testing than other parts of the stack, even though it needs it more. So, options as I see them: * don't depend on gtk 2.8. This is suboptimal for all of us, in that gtk gets less testing, is less stable, etc., but goes a long way towards guaranteeing a reliable platform for GNOME 2.12 development and deployment, which is important for everyone. * tentatively depend on 2.8, and if 2.8 is not reliable when we need to ship 2.12, punt all apps that have chosen to depend on 2.8 and can't remove those dependencies in time. This is pretty suboptimal, in that developers will be forced to make a choice- depend on 2.8 and risk being tossed from the release, or go the safe route, but not get the new features, and not contribute to testing. * do a hard
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote: [Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) Luis As distribution packager, I already followed the DBUS 0.3x road once, and it went dead because it seems only gnome and freedesktop are picking up the new APIs. How will interoperability with other programs, like for example, KDE look in the near future with DBUS 0.3x? As it looks now, I can't provide prerelease packages to our users without breaking KDE for them, which is bad (I build gnome-vfs without DBUS in my prerelease packages, but I don't think that option will last very long) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-keyring-manager in 2.12
Seems to me that gnome-keyring-manager should at a minimum go into meta-gnome-proposed in jhbuild*, and seems (to me) to fill a fairly important need for key management, and should probably be in 2.12. Anyone have any thoughts on this? For reference, it wasn't in 2.8 because of issues addressed here: http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg00412.html the usability list thread in the 2.9 timeframe did not seem to go very far: http://mail.gnome.org/archives/usability/2004-December/msg4.html but some new UI was committed in January of this year, and having just used it for the first time, it seemed to suitably hide the keyring issues I wasn't interested in (which is basically all of them, since I'm still not completely sure what the hell a keyring is :) So... anyone? Bueller? Luis * which I'll do tonight if there are no objections ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On Fri, 2005-06-10 at 19:43 +0200, Jan de Groot wrote: On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote: [Moving this off r-t to a broader group that might have more feedback on this :) On 6/10/05, Vincent Untz [EMAIL PROTECTED] wrote: On Fri, June 10, 2005 15:22, Ross Burton said: I think the release team need to make a statement about what version of DBus is to be used for any code which can use DBus. At present I believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas nautilus-cd-burn is still using 0.2x. As these cannot be easily used at the same time, this needs to be resolved one way or another. Good point. I think that the distributors that will ship 2.12 will use DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible solution to me. Is there any reason to stay with the 0.2x API? Yeah, I don't know of any reason not to standardize on 0.3x- most things have already ported AFAICS. d-d-l, anyone object to requiring everyone to move to 0.3x? (I'm assuming no, but...) Luis As distribution packager, I already followed the DBUS 0.3x road once, and it went dead because it seems only gnome and freedesktop are picking up the new APIs. How will interoperability with other programs, like for example, KDE look in the near future with DBUS 0.3x? As it looks now, I can't provide prerelease packages to our users without breaking KDE for them, which is bad (I build gnome-vfs without DBUS in my prerelease packages, but I don't think that option will last very long) Turn off support in KDE or patch the applications. I don't think it uses DBus for much. Qt4 will be using DBus extensively from what I hear. The thing is 0.2x was added to distributions so that people could play with it and those who were willing to wade the waters of a changing API could do useful stuff with it. It really is a dead branch though and I really don't want to promote its use any longer. It will just get harder to switch once we do reach 1.0 and commit API/ABI stability. Uptake on the library was faster than what we had expected (a testiment to its utility) but we are going to have to feel the pain at some point and now is the best time. Point being, staying on 0.2x just digs a bigger hole of which one would need to climb out of. The release I want to do next week should be for the most part API stable up to 1.0 (baring any limitations the Qt4 people find). At least we won't be seeing the massive changes that took place between 0.2x to 0.3x so lets get it over with and not prolong the inevitable. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As Marco points out, we have the possibility to bail out and re-enable the splash backend at any time, should we decide that the cairo backend is not ready. In the meantime, I'd like to enable the cairo backend by default so it gets a lot of testing. People are already using poppler with cairo and logging bugs about slow PDFs or incorrect rendering, and the current cvs head has improved much based on those reports already. I'd love to see more of this so we can close the gap between the cairo backend and the splash backend and hopefully make cairo itself faster in the process. With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? BTW, Nagappan- does LDTP have any timed testing capabilities so it can be used for performance testing? Seems like evince and some of the other things switching to cairo would be a great target for that if LDTP has the capability. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa [EMAIL PROTECTED] writes: On 6/10/05, Kristian Hgsberg [EMAIL PROTECTED] wrote: With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? poppler already builds w/ cairo by default if it finds it. Just adding the dependency on cairo in jhbuild should be sufficient. Thanks, -Jonathan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa wrote: On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As Marco points out, we have the possibility to bail out and re-enable the splash backend at any time, should we decide that the cairo backend is not ready. In the meantime, I'd like to enable the cairo backend by default so it gets a lot of testing. People are already using poppler with cairo and logging bugs about slow PDFs or incorrect rendering, and the current cvs head has improved much based on those reports already. I'd love to see more of this so we can close the gap between the cairo backend and the splash backend and hopefully make cairo itself faster in the process. With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? It shouldn't be necessary to do anything -- the backend choice is in poppler at configure time. If cairo = 0.5 is available, poppler will default to the cairo backend. I was basically just arguing that we shouldn't switch jhbuild to the splash backend. cheers, Kristian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
On 10 Jun 2005 15:33:58 -0400, Jonathan Blandford [EMAIL PROTECTED] wrote: Luis Villa [EMAIL PROTECTED] writes: On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? poppler already builds w/ cairo by default if it finds it. Just adding the dependency on cairo in jhbuild should be sufficient. OK. ATM jhbuilt gtk requires cairo, so evince shouldn't need any changes. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 13:10 -0400, Luis Villa wrote: On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, As an aside, when I say 'stable', I mean 'reliable for users', not 'API stable for developers', and maybe that is part of the confusion of this thread. I expect GNOME .0s to be both stable (in your sense) and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not reliable in mine, and that is why release team is wary of telling people that a gnome .0 based on gtk 2.8.0 would be reliable. but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. I'm not claiming we do or should. You get to release .0 whenever you want, and users get to use it whenever they want. Release-team gets to say when they think it is reliable, and hence worthy of being part of GNOME. Ideally your .0 and our .0 should have the same qualities, but in our past experience they have not. I'd argue that we may well be straying to far on the reliable side for GNOME. I'm not convinced we can do interesting development, stabilize down completely, and release on a 6 month time schedule. If we want to get real world testing before the code freeze, then we have to have something that a lot of people are using within 4 months after the release cycle opens. Acknowledging that the initial release may have a few rough edges gives us some pipelining, where the final stabilization of the last cycle gets parallelized with the start of development of the next release set. I'm not arguing for any radical changes here, just the realization that the only way you get zero-boogs is by having zero-development. If we don't do that, then I think we need to think about switching to having phased releases of some sort (like the old RHL 6.0, 6.1, 6.2, 7.0 model) This whole conversation is unfortunately sounding very hostile, which was not my intent. Let me try to back it down a little bit and get it back to the first principles, explain why (IMHO) gtk 2.4.0 was not reliable enough for GNOME 2.6.0, and see if/where/when we can compromise from those. With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full three months before GNOME 2.10 was, allowing for extensive testing and several GTK point releases. Avoiding a repeat of this very difficult problem is my primary concern. I think this is slightly exaggerating the situation ... there were definitely issues with the file selector, but the file selector wasn't used *that* extensively in 2.6.0. And on the other side, the file selector had been under development for quite a while, but there is only so far you can go in an unused version of GTK+ ... it took about a year of real world banging on the file chooser for it to get to a state that's pretty satisfactory now. 2.8.0/2.10.0 were almost certainly a better release because the file selector appeared in GNOME-2.6.0. Let me reiterate that the version of GTK+ that goes into GNOME-2.12 is up to the release team. At this point, GNOME-2.12 isn't going to be depending on Cairo in interesting ways, so there wouldn't be huge disruption from making GTK+-2.6.x the official GNOME-2.12 version. But I really do want to get Cairo out there and in use as soon as possible and we'll be putting Cairo/Pango-1.9/GTK+-2.7
Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]
On Fri, 2005-06-10 at 19:43 +0200, Jan de Groot wrote: As distribution packager, I already followed the DBUS 0.3x road once, and it went dead because it seems only gnome and freedesktop are picking up the new APIs. How will interoperability with other programs, like for example, KDE look in the near future with DBUS 0.3x? This message http://lists.freedesktop.org/archives/hal/2005-March/002363.html suggests that KDE HEAD is already using hal 0.5.x and dbus 0.3x since sometime in March. IIRC all the KDE stuff use only dbus through libhal and the libhal changes from hal 0.4.x to hal 0.5.x are mostly trivial. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 17:49 -0400, Morten Welinder wrote: the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for hello world. You need to consider something bigger! Thanks for telling me how I designed the gtk+/cairo integration, I had no idea. Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Rendering speed is 90% an X server issue. For non-local servers without Render, Cairo will allow us to eliminate the round-trips... a huge win. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. We love you too, Morten. Best regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Owen, the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for hello world. You need to consider something bigger! Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. Glib 2.8, on the other hand, fine. That's not a revolution. It might as well get renamed back to 2.6.whatever. And btw., we still are not near a state where the file chooser is acceptable. The save-as mode really stinks while the open mode is only marginally acceptable. See http://blogs.gnome.org/view/mortenw/2005/05/25/1 for example. Morten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
