GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Hi all, I only discovered this morning by looking at James commit for jhbuild that GNOME 2.11/2.12 is supposed to ship with GTK+ 2.8 (and therefore Cairo) which might not have been obvious for anybody reading http://live.gnome.org/RoadMap (since there is only a reference to cairo used to replace libgnomecanvas/libart). And I'm not sure all GNOME hackers have realized we are supposed to switch to GTK+ 2.8/Cairo. Since I'm kind of conservative and pessimist guy (working for a vendor and being a release team member probably doesn't help for that :), I'm a little worried that we base our next stable of GNOME on a yet to be released version of GTK+ which is supposed to change a lot of things internally for GTK+, which might also impact GNOME software. Could GTK+ hackers give us a status of GTK+ 2.8, compared to their plans from http://gtk.org/plan/2.8/ ? Don't get me wrong, I don't want to undermine GTK+ hackers works, but I feel we should clarify the situation for everybody best interest. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ 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/8/05, Mark McLoughlin [EMAIL PROTECTED] wrote: Hey, I guess there's quite a few benefits/risks to be weighed up here: - The benefit of having cool new rendering stuff in GNOME 2.12 - The benefit of being able to use all the other new APIs in GTK+ 2.8 for GNOME 2.12 - The benefit of getting all this stuff tested early (i.e. before GTK+ 2.8 is released, rather than after) I'm all in favor of *testing* gtk 2.8 as much as possible now (so I think it should be left in jhbuild), but I'm very nervous about shipping with it at this point- we all know HEAD does not get as much testing as it should, and gtk 2.8 seems like some very big changes with potentially huge stability implications. Basically, unless Ubuntu breezy starts shipping it, or Fedora makes a very active push to get people to use it in Rawhide, I'm very nervous about shipping anything we'd call a .0 linking against gtk 2.8. Luis - The extra incentive for people to help with getting the rendering stuff optimized vs. - The risk of the GTK+ 2.8 schedule slipping, causing a slip in the GNOME 2.12 schedule - The risk that performance problems with the rendering stuff might put some people off using GNOME 2.12 Although I was pretty nervous about this too at first, the benefits certainly seem to outweigh the risks when you spell them out like that. Cheers, Mark. ___ 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: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/8/05, Mark McLoughlin [EMAIL PROTECTED] wrote: Hey, I guess there's quite a few benefits/risks to be weighed up here: - The benefit of having cool new rendering stuff in GNOME 2.12 - The benefit of being able to use all the other new APIs in GTK+ 2.8 for GNOME 2.12 - The benefit of getting all this stuff tested early (i.e. before GTK+ 2.8 is released, rather than after) I'm all in favor of *testing* gtk 2.8 as much as possible now (so I think it should be left in jhbuild), but I'm very nervous about shipping with it at this point- we all know HEAD does not get as much testing as it should, and gtk 2.8 seems like some very big changes with potentially huge stability implications. Basically, unless Ubuntu breezy starts shipping it, or Fedora makes a very active push to get people to use it in Rawhide, I'm very nervous about shipping anything we'd call a .0 linking against gtk 2.8. Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, since it jeopardizes our release schedule for something that is less tested than the rest of the stack and which in many cases isn't widely used because developers haven't had time to integrate it. I suppose we could reconsider that, but we did it the last time for the same reasons Mark listed, more or less. As a result we had to delay our release and (speaking with my QA hat on) after .0 we still had to track down several issues in gtk that were caused by rushing out a component low-in-the-stack with insufficient real-world testing. So, yeah, I'm pretty strongly against this, though I'm open to persuasion. 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 Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, [snip] I think we'd love them to be in sync. They are getting there, and if they are there, I think we'd be happy with that. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.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 Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: So, yeah, I'm pretty strongly against this, though I'm open to persuasion. aolMe too/aol, for all the reasons Luis listed. I remember our r-t discussions basically concluded that we'd made a mistake depending on GTK+ for 2.6. 2.6 had stability issues. -- Andrew ___ 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)
I guess a fair compromise would be to aim for using gtk 2.8 for 2.12, but not using any new functionality in gtk 2.8. That way if it turns out 2.8 is not stable enough we can roll back to 2.6 before release. On the other side it is stable enough then we ensure its gets widely distributed and tested so we can start taking advantage of it for 2.14. Christian On Wed, 2005-06-08 at 14:42 +0100, Andrew Sobala wrote: On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: So, yeah, I'm pretty strongly against this, though I'm open to persuasion. aolMe too/aol, for all the reasons Luis listed. I remember our r-t discussions basically concluded that we'd made a mistake depending on GTK+ for 2.6. 2.6 had stability issues. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
On Wed, 2005-06-08 at 17:52 +0200, Danilo egan wrote: I support this initiative by Frederic, and let me add that apart from misreferenced gettext domain names, it's not uncommon for programmers to miss appropriate calls to set up translation when they switch to GtkUIManager (from GtkItemFactory) or even miss to set up translation domain when they load in .glade files: these kinds of omissions are usually reflected in application menus being untranslated, so you can notice them quite fast. 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 Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
Today at 16:27, Frederic Crozat wrote: So, if you are a non-english native speaker GNOME hacker (or if you are fluent enough to use GNOME in another language than english), please use it by default on your system and report bugs (when translations is there but not displayed). And of course, this call is also valid for translators who usually know which parts of applications they have already translated. I support this initiative by Frederic, and let me add that apart from misreferenced gettext domain names, it's not uncommon for programmers to miss appropriate calls to set up translation when they switch to GtkUIManager (from GtkItemFactory) or even miss to set up translation domain when they load in .glade files: these kinds of omissions are usually reflected in application menus being untranslated, so you can notice them quite fast. Btw, Frederic, what were the untranslated applications you noticed? I'm running 2.10 since it came out and I didn't notice any regressions in the apps I regularly use. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
Le mercredi 08 juin 2005 à 17:52 +0200, Danilo ¦egan a écrit : Btw, Frederic, what were the untranslated applications you noticed? I'm running 2.10 since it came out and I didn't notice any regressions in the apps I regularly use. Regression were usually not application wide, but in part of applications. I specifically noticed the starting xxx button in taskbar when you are starting an application because I fixed the translation bug two years ago and it reappeared in 2.10. It is now fixed in CVS. Evolution is also regressing since eplugin are not translated at all (infrastructure has been only added for HEAD), but I have sent a specific mail for that. There are probably other applications (I noticed some at GUADEC on other people system) but I didn't had time to write about them. I plan to check this after my holidays, which means starting in July (since Mandriva will be shipping GNOME 2.10.x for next release). -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
