Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le mardi 15 juin 2010 à 11:28 -0400, Behdad Esfahbod a écrit : On 06/15/2010 11:03 AM, Maciej Piechotka wrote: However please correct me if I'm wrong. You are not wrong, but off point. What I'm saying is that (unlike what Josselin said) symbol versioning doesn't fix any problem in gtk+. I'm not talking about any other library. We talked about it today on #debian-devel, and it turns out there is a very serious problem that is fixed by symbol versioning in GTK+. $ objdump -p /usr/lib/mozilla/plugins/libflashplayer.so [snip] NEEDED libgtk-x11-2.0.so.0 Now load this plugin in an epiphany or firefox process built against GTK3, and have fun. The problem doesn’t happen with versioned symbols, since the plugin and the browser don’t exchange widgets. The Qt maintainer raised similar concerns with konqueror using QGtkStyle, which uses GTK2 to draw widgets, with the totem browser plugin built against GTK+ 3. -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `-and I am praying for you.” -- Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, Aug 3, 2010 at 2:19 PM, Josselin Mouette j...@debian.org wrote: We talked about it today on #debian-devel, and it turns out there is a very serious problem that is fixed by symbol versioning in GTK+. $ objdump -p /usr/lib/mozilla/plugins/libflashplayer.so [snip] NEEDED libgtk-x11-2.0.so.0 Now load this plugin in an epiphany or firefox process built against GTK3, and have fun. The problem doesn’t happen with versioned symbols, since the plugin and the browser don’t exchange widgets. The Qt maintainer raised similar concerns with konqueror using QGtkStyle, which uses GTK2 to draw widgets, with the totem browser plugin built against GTK+ 3. I think latest Firefox should work fine, since they run the plugins in a different process. We are checking the feasibility of doing the same for WebKitGTK+ before GNOME 3.0, which would also solve the issue. Which is to say, it would be nice if we didn't have the problem in the first place, but a solution for it is definitely in our plans. Xan -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `- and I am praying for you.” -- Mike ___ 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le mardi 03 août 2010 à 19:17 +0200, Xan Lopez a écrit : On Tue, Aug 3, 2010 at 2:19 PM, Josselin Mouette j...@debian.org wrote: We talked about it today on #debian-devel, and it turns out there is a very serious problem that is fixed by symbol versioning in GTK+. $ objdump -p /usr/lib/mozilla/plugins/libflashplayer.so [snip] NEEDED libgtk-x11-2.0.so.0 Now load this plugin in an epiphany or firefox process built against GTK3, and have fun. I think latest Firefox should work fine, since they run the plugins in a different process. We are checking the feasibility of doing the same for WebKitGTK+ before GNOME 3.0, which would also solve the issue. Which is to say, it would be nice if we didn't have the problem in the first place, but a solution for it is definitely in our plans. It depends on the mechanism used to launch the plugin processes. If they still have the webkit or mozilla libraries, that won’t be enoug. Not to say it’s not easy to do the correct way, but it has to be done. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Hi! Moreover, could we stagger the 2.31.4 tarball due date for applications by a couple days? That would give application maintainers a chance to build against newly-released gtk3-dependent libraries and do some quick smoke testing before releasing their own tarballs. If we try to release both gtk3-dependent libraries and applications simultaneously I fear it's gonna to be a train wreck. Any opinion of the release-team here? I think that is a real good idea to make things a little easier for everybody. Regards, Johannes 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Mon, 2010-06-14 at 22:33 -0400, Matthias Clasen wrote: On Mon, Jun 14, 2010 at 6:12 AM, Sebastien Bacher seb...@ubuntu.com wrote: [...] our one CD constraint will make challenging to ship 2 versions of the GTK stack. I would take this a somewhat seriously, if it did not come from the distribution that embraced desktop-couch and 60+ M of erlang dependencies... Realistically we aim at doing the packaging work and getting GTK3 in shape and in main this cycle but not in the default installation, we have planned the GNOME3 transition for Ubuntu over 2 cycles. So the upshot is that GNOME3 will be happening without contributions from your side, while your team is busy building their own desktop experience with Ayatana and unity. Thats ok, lets just be honest about it and stop pretending. That's not fair. Maybe we've become too used to distros shipping the very latest upstream code in regular releases and forgotten how lucky we are that it's possible most of the time. A little caution around GTK+ 3 seems wise. It's an ABI break requiring lots of integration work and it's hard for any distro to assume that GNOME will get it done in time, let alone that the distro will solve all their own integration problems in time. And that's not even mentioning the major feature and UI changes from GNOME Shell. -- murr...@murrayc.com 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 06/15/2010 03:05 AM, John Stowers wrote: AFAIK (and please correct me if I am wrong), but the story is the same for PyGtk; it builds against Gtk-2.0 and not 3.0. * What does this mean for Python apps and GNOME 3.0 / 2.31 The current plan seems to be that people should be transitioning away from pygtk to pygi. I guess people would love to see a similar gi# for mono bindings as well? There is also the case of apps like Rhythmbox, Totem, Gedit, that support PyGtk plugins * Will these apps lose plugin support this cycle? I can't speak for all the listed apps, but gedit plans on using libpeas for plugin support in the gtk+-3-based branch, and use pygi. It also means breaking the compatibility with old plugins but otoh it's already broken for the switch to gtk+ 3 If for some reason the pygi state is not satisfying for the release, then it will still be possible to make a new release out of the gtk2 branch. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 22:33 -0400, Matthias Clasen a écrit : I would take this a somewhat seriously, if it did not come from the distribution that embraced desktop-couch and 60+ M of erlang dependencies... Hi, Not sure such comments are constructive there. We do believe that desktopcouch is a nice technology and we decided to base some of the things we are doing on it. We didn't write it though and the erlang depends is coming with it. I fail to see why GNOME should judge distribution choices the way you are doing, we are still using GNOME as our default desktop and the fact that some of the choices we are making create some extra work for us shouldn't be a concern for GNOME. My email was just explaining what Ubuntu will be doing and why. So the upshot is that GNOME3 will be happening without contributions from your side I'm not sure to understand. I said we do plan to get there over 2 cycles, that we will get the platform GNOME3 and GTK3 ready this cycle but our default desktop will depends on it only next cycle (we will likely have GNOME3 in a ppa for this cycle for the users who want it). How is doing the work over two cycles and taking some time before switching not contributing? We will do what we can to help on GNOME3 and will be shipping it, we just believe our distribution doesn't have the capacity to make it happen by default for our users with our quality requirement in this cycle. while your team is busy building their own desktop experience with Ayatana and unity. Thats ok, lets just be honest about it and stop pretending. Not sure what you call your team there, the Canonical Dxteam is working on unity, my team which is the Canonical Desktop Team is working on the Ubuntu desktop, we are working on GNOME as we did since Ubuntu started and we do plan to work on landing GNOME3 in the desktop, it's just going to take us two cycles for the reason explaining before. The fact that other teams at Canonical work on some other projects doesn't mean we will stop using GNOME or contributing, we just have different products to respond to different customers and users needs. Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 23:17 +0200, Andy Wingo a écrit : People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). Which will seriously break unless people are willing to add versioned symbols to GTK+. It's not the last word, but there's definitely something to be said for reducing the configuration and bug space by requiring a specific ABI. Yes. Anything that is not an end-user application, be it a binding, a library or whatever, needs to expose a different interface depending on whether it is built against GTK+ 2.x or 3.x. -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 06/15/2010 12:11 PM, Josselin Mouette wrote: Le lundi 14 juin 2010 à 23:17 +0200, Andy Wingo a écrit : People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). Which will seriously break unless people are willing to add versioned symbols to GTK+. It would also break with versioned symbols as some struct layouts have changed between gtk2 and gtk3 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, Jun 15, 2010 at 03:05, John Stowers john.stowers.li...@gmail.com wrote: A separate but related issue is that unless somebody plans to update gtk-sharp, Tomboy may not be GTK3 compatible this cycle (I don't know off-hand what parts of gtk-sharp may be incompatible with GTK3). Do other non-C apps have similar issues, or is this just a problem with the Mono bindings? AFAIK (and please correct me if I am wrong), but the story is the same for PyGtk; it builds against Gtk-2.0 and not 3.0. * What does this mean for Python apps and GNOME 3.0 / 2.31 To the best of my knowledge, nobody has stepped yet to make PyGtk work with Gtk+ 3.0. But PyGI's goal is to work with both 2.0 and 3.0, provided the needed annotation fixes are accepted in the 2.0 branch. Regards, Tomeu There is also the case of apps like Rhythmbox, Totem, Gedit, that support PyGtk plugins * Will these apps lose plugin support this cycle? John ___ 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, Jun 15, 2010 at 6:11 AM, Josselin Mouette j...@debian.org wrote: Le lundi 14 juin 2010 à 23:17 +0200, Andy Wingo a écrit : People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). Which will seriously break unless people are willing to add versioned symbols to GTK+. You can keep repeating that over and over. That does not make true. Symbol versions will not differentiate types, signals, etc over abi boundaries. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le mardi 15 juin 2010 à 07:20 -0400, Matthias Clasen a écrit : On Tue, Jun 15, 2010 at 6:11 AM, Josselin Mouette j...@debian.org wrote: Le lundi 14 juin 2010 à 23:17 +0200, Andy Wingo a écrit : People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). Which will seriously break unless people are willing to add versioned symbols to GTK+. You can keep repeating that over and over. That does not make true. Symbol versions will not differentiate types, signals, etc over abi boundaries. This is completely irrelevant, since the pieces built against one version will use the appropriate types, signals, etc. with the functions of the GTK+ version they are built against. Do you really think GTK+ is the first library with which we encounter such an issue? -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, Jun 15, 2010 at 7:32 AM, Josselin Mouette j...@debian.org wrote: This is completely irrelevant, since the pieces built against one version will use the appropriate types, signals, etc. with the functions of the GTK+ version they are built against. Right, so there will be two completely separate type trees, with GtkWidget_2 and GtkWidget_3 types. Now...what ? Do you really think GTK+ is the first library with which we encounter such an issue? Great that you are an expert in these matters. Then we don't have to bitch about this, you can simply convince me by demonstrating how well this works in practice. Here is the challenge: I want to see a widget tree that contains both gtk3 widgets and widgets originating from a library linked against gtk2, and I want to see the app survive global events like a theme change. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
FWIW, Last time this was raised was May 18 onwards: http://mail.gnome.org/archives/desktop-devel-list/2010-May/msg00075.html One of the messages mentioned that there haven't been much changes since 2005 to discuss this again (May 18): http://mail.gnome.org/archives/desktop-devel-list/2010-May/msg00091.html Combining both, seems that it is a bit premature to repeat this discussion again on d-d-l. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 06/15/2010 07:32 AM, Josselin Mouette wrote: This is completely irrelevant, since the pieces built against one version will use the appropriate types, signals, etc. with the functions of the GTK+ version they are built against. So, my application uses libraries A and B. It takes a GtkWidget from A, and passes it to a function in B. If A links against gtk-2.0 and B links against gtk-3.0, tell me exactly how does symbol versioning address this? Do you really think GTK+ is the first library with which we encounter such an issue? What are some other examples that are parallel installable and use symbol versioning in the way that was proposed on this list? behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit : So, my application uses libraries A and B. It takes a GtkWidget from A, and passes it to a function in B. If A links against gtk-2.0 and B links against gtk-3.0, tell me exactly how does symbol versioning address this? It doesn’t, of course. It will not magically solve all coinstallability problems, just a subset of them. As soon as the application exposes widgets from both libraries, you’re pretty much doomed. Do you really think GTK+ is the first library with which we encounter such an issue? What are some other examples that are parallel installable and use symbol versioning in the way that was proposed on this list? For example there’s libpng, and libjpeg is underway. But of course this won’t solve cases of passing a libpng structure from a higher-level library to another one. -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 06/15/2010 09:27 AM, Josselin Mouette wrote: Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit : So, my application uses libraries A and B. It takes a GtkWidget from A, and passes it to a function in B. If A links against gtk-2.0 and B links against gtk-3.0, tell me exactly how does symbol versioning address this? It doesn’t, of course. It will not magically solve all coinstallability problems, just a subset of them. As soon as the application exposes widgets from both libraries, you’re pretty much doomed. So, which problems *does* it solve? (except for inferring minimum version of the library required at runtime) Isn't GTK+ by nature designed such that all widgets eventually are painted by on version of the library, and hence simply no way to have two in process without passing structs from one to the other? Plus, what would you do to glib's type system? Only one of the Gtk's can add the gtype GtkWidget. Which means, it wouldn't work even if not passing structs from one version to the other... Do you really think GTK+ is the first library with which we encounter such an issue? What are some other examples that are parallel installable and use symbol versioning in the way that was proposed on this list? For example there’s libpng, and libjpeg is underway. But of course this won’t solve cases of passing a libpng structure from a higher-level library to another one. Lets be fair: those use cases are inherently much simpler and much more limited and contained. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, 2010-06-15 at 09:36 -0400, Behdad Esfahbod wrote: On 06/15/2010 09:27 AM, Josselin Mouette wrote: Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit : So, my application uses libraries A and B. It takes a GtkWidget from A, and passes it to a function in B. If A links against gtk-2.0 and B links against gtk-3.0, tell me exactly how does symbol versioning address this? It doesn’t, of course. It will not magically solve all coinstallability problems, just a subset of them. As soon as the application exposes widgets from both libraries, you’re pretty much doomed. So, which problems *does* it solve? (except for inferring minimum version of the library required at runtime) Isn't GTK+ by nature designed such that all widgets eventually are painted by on version of the library, and hence simply no way to have two in process without passing structs from one to the other? Plus, what would you do to glib's type system? Only one of the Gtk's can add the gtype GtkWidget. Which means, it wouldn't work even if not passing structs from one version to the other... As far as I understand it helps with the 'hidden' dependencies. I.e. if package A depends on B which depends on D in version 1.0 and A depends on C which depends on D in version 2.0 but B and C does not expose D interface. If D is libpng B may be gdk and C may be imagemagic. Both links against the same library (D) however both do not expose the ABI and hence it do not clash. In general it should help (I believe) if A does not depend directly on D (not only in terms of linking symbols) - I guess the in gtk+ it won't help but there may be some cases when it helps with glib. However please correct me if I'm wrong. Regards 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 06/15/2010 11:03 AM, Maciej Piechotka wrote: However please correct me if I'm wrong. You are not wrong, but off point. What I'm saying is that (unlike what Josselin said) symbol versioning doesn't fix any problem in gtk+. I'm not talking about any other library. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le mardi 15 juin 2010 à 09:36 -0400, Behdad Esfahbod a écrit : So, which problems *does* it solve? (except for inferring minimum version of the library required at runtime) Isn't GTK+ by nature designed such that all widgets eventually are painted by on version of the library, and hence simply no way to have two in process without passing structs from one to the other? Sure. Quoting myself last month: “I don’t expect many libraries that link against one GTK+ version to be usable by a program linking to the other GTK+ version”. Sorry for replying a bit too fast earlier, and before Matthias goes down his slope of sarcasm to the point of being insulting, I will correct myself. Which will seriously break unless people are willing to add versioned symbols to GTK+. Should have been: Which will seriously break, except in some special corner cases if versioned symbols are added. I was more focused on replying to the end of the mail, which is about something much more important right now than discussing a hypothetical feature - one that is, regardless of the numerous problems you pointed out, not interesting anyway since it hasn’t been added earlier. For example I would be worried to have pygtk expose the same interface for 3.0 and 2.0, like it used to do at the time of the 1.2 → 2.0 transition. -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, 2010-06-12 at 22:36 -0400, Michael Terry wrote: On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome seems the situation has changed, and GTK3 will be available in Universe, but not on the CD, and all apps are going to be linked against GTK2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 10:43 +0200, Rodrigo Moya a écrit : seems the situation has changed, and GTK3 will be available in Universe, but not on the CD, and all apps are going to be linked against GTK2 But is it very likely that Ubuntu CD will contain applications that still require GTK+2? If you have a look at the list published recently by Andre, it seems we're pretty close to the goal: http://blogs.gnome.org/aklapper/2010/06/10/heads-up-gnome-2-31-soon-to-ship-gtk-2-90/ And Ubuntu default packages aren't that esoteric, are they? It seems to me that fixing the few apps that still depend on GTK+2 would be less work than backporting features to 2.22 and cherry-picking change for modules that couldn't enter 10.10 because they require GTK+3. I mean: as an Ubuntu user and contributor, I'm tired of seeing that this distribution is considering itself as pure downstream, and would rather patch all they can rather than spend this effort helping the move in GNOME itself. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le samedi 12 juin 2010 à 16:55 +0100, Bastien Nocera a écrit : And you're telling me that your decision on keeping a GTK+ 2.x version is based on one distributor's dubious decision? GNOME 3.x will be based on GTK+ 3.x. Hey Bastien, We wouldn't be the first distribution to work on a GNOME version not being the most recent one for a cycle, that's a distribution choice and I'm not sure why it would be dubious? Take in account that some distributions out there are available and used and without gtk3 and will keep being used for a while (Debian, OpenSuse, RHEL, Ubuntu LTS, etc). It's reasonable for software writers to support having their new version to still build on those distribution to reach those users, why would you require everybody to drop gtk2 support? Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 10:53 +0200, Milan Bouchet-Valat a écrit : But is it very likely that Ubuntu CD will contain applications that still require GTK+2? Yes, I don't see for example firefox or openoffice switch to gtk3 in this cycle. this distribution is considering itself as pure downstream, and would rather patch all they can rather than spend this effort helping the move in GNOME itself. We do plan to help moving, we just don't think Ubuntu will be able to deal will all those transitions in one cycle Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le samedi 12 juin 2010 à 17:31 +0200, Xavier Claessens a écrit : Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3, and if we can't build Empathy with GTK2 then they'll just keep Empathy 2.30.x... tbh I think that's a bad decision from Ubuntu, but it would be really sad to not ship the latest empathy... Hi, It's not that easy. The Ubuntu team does think GNOME3 is moving in the right direction and that GTK3 will be great and wants to help to get there. In the same time we need to ship in octobre something solid our users rely on. We did discuss it a lot and the distribution might be quite popular our team is still quite small with limited manpower, the GTK3 transition will require quite some packaging work to build GTK3 versions of all those libraries and our one CD constraint will make challenging to ship 2 versions of the GTK stack. Realistically we aim at doing the packaging work and getting GTK3 in shape and in main this cycle but not in the default installation, we have planned the GNOME3 transition for Ubuntu over 2 cycles. But I guess if the whole GNOME 2.32 depends on GTK3 then they'll change their mind. No, we will just ship what we have now and keep working over 2 cycles on the GNOME3 update. One side note is that lot of users out there are on stable distributions versions which don't have GTK. Those distributions will not change for a while and those users will stay there. Now softwares writers have the choice to stop targeting those users and stop allowing GTK2 builds of their code or to allow building with either GTK2 and GTK3. I guess lot of upstreams out of GNOME will keep supporting GTK2 for some years which is a reasonable position, what matters for most upstream is to have their code used. I doubt that for example firefox or openoffice will drop support for GTK2 builds any time. I don't think because a software is part of GNOME means it should hard require GTK3 now and stop building on GTK2, it should rather be a maintainer decision on what they want for their software and users. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Mon, 2010-06-14 at 11:58 +0200, Sebastien Bacher wrote: Le samedi 12 juin 2010 à 16:55 +0100, Bastien Nocera a écrit : And you're telling me that your decision on keeping a GTK+ 2.x version is based on one distributor's dubious decision? GNOME 3.x will be based on GTK+ 3.x. Hey Bastien, We wouldn't be the first distribution to work on a GNOME version not being the most recent one for a cycle, that's a distribution choice and I'm not sure why it would be dubious? Take in account that some distributions out there are available and used and without gtk3 and will keep being used for a while (Debian, OpenSuse, RHEL, Ubuntu LTS, etc). It's reasonable for software writers to support having their new version to still build on those distribution to reach those users, why would you require everybody to drop gtk2 support? That's not a decision for the software writers to make when their code is in the GNOME release. And I'm saying they'd be better off maintaining separate branches if they want to keep a GTK+ 2.x version. I don't see how that's a different problem from GNOME as a whole using a newer glib and pushing modules to use the new functionality. If OO.o or Firefox are blockers, where's the push to get those building against GTK+ 3.x? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 11:38 +0100, Bastien Nocera a écrit : That's not a decision for the software writers to make when their code is in the GNOME release. Why would GNOME tell software writers that their code can't have build time options to use either gtk2 or gtk3? I don't see how that's a different problem from GNOME as a whole using a newer glib and pushing modules to use the new functionality. It's not really but GNOME never had rules saying that maintainers can't decide to add support for older version in their code if the newest glib is not available at build time. If OO.o or Firefox are blockers, where's the push to get those building against GTK+ 3.x? Not sure for who they are blocker, those are not part of GNOME and GNOME should not take decisions based on those. Distributors in the other side often have different requirements and take their decisions based on those. We will try to work on helping making those to build with GTK3, we just plan this work on several cycles for reason explained before. -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Hi! I don't see how that's a different problem from GNOME as a whole using a newer glib and pushing modules to use the new functionality. It's not really but GNOME never had rules saying that maintainers can't decide to add support for older version in their code if the newest glib is not available at build time. Just from the point of a module maintainer: Yes, we will have an option to support gtk2 builds for now as none of our developers is using a environment that has gtk3 at the moment (meaning most are not on jhbuild). But we plan to drop support more or less as soon as GNOME 3 is out maybe even ealier if we use the GApplication/GtkApplication API. We will no maintain a version compatible with older libraries in the future. You also spoke about targetting long-term releases of distributions: In short, speaking of me, I don't, because there are many of them and they use different library versions. Code changes too fast to keep compatibility. As such, they may use our old stable releases but there won't be any support. I think it would be awesome if Ubuntu shipped Gtk+-3.0 as default (read: live-cd) and Gtk+-2.0 for compatibility for other apps but it is your decision. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Mon 14 Jun 2010 12:57, Sebastien Bacher seb...@ubuntu.com writes: Le lundi 14 juin 2010 à 11:38 +0100, Bastien Nocera a écrit : That's not a decision for the software writers to make when their code is in the GNOME release. Why would GNOME tell software writers that their code can't have build time options to use either gtk2 or gtk3? People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). It's not the last word, but there's definitely something to be said for reducing the configuration and bug space by requiring a specific ABI. Cheers, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
A separate but related issue is that unless somebody plans to update gtk-sharp, Tomboy may not be GTK3 compatible this cycle (I don't know off-hand what parts of gtk-sharp may be incompatible with GTK3). Do other non-C apps have similar issues, or is this just a problem with the Mono bindings? AFAIK (and please correct me if I am wrong), but the story is the same for PyGtk; it builds against Gtk-2.0 and not 3.0. * What does this mean for Python apps and GNOME 3.0 / 2.31 There is also the case of apps like Rhythmbox, Totem, Gedit, that support PyGtk plugins * Will these apps lose plugin support this cycle? John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Mon, Jun 14, 2010 at 6:12 AM, Sebastien Bacher seb...@ubuntu.com wrote: [...] our one CD constraint will make challenging to ship 2 versions of the GTK stack. I would take this a somewhat seriously, if it did not come from the distribution that embraced desktop-couch and 60+ M of erlang dependencies... Realistically we aim at doing the packaging work and getting GTK3 in shape and in main this cycle but not in the default installation, we have planned the GNOME3 transition for Ubuntu over 2 cycles. So the upshot is that GNOME3 will be happening without contributions from your side, while your team is busy building their own desktop experience with Ayatana and unity. Thats ok, lets just be honest about it and stop pretending. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le 13/06/10 04:36, Michael Terry a écrit : On 12 June 2010 11:31, Xavier Claessensxclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome Talked to an ubuntu dev, their problem is they don't have enough free space on the liveCD to have version 2 and 3 of all libraries. And I doubt we'll be able to port all app that they ship on the liveCD to gtk3 in time... Or could we? Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Bastien Nocera wrote: To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) https://bugzilla.gnome.org/show_bug.cgi?id=618473 Emmanuele could do a release. If we were to follow our rules on external dependencies it would be *required* to have a release (and then discussion bumping, but that's a formality) before we have modules depending on libunique-3. Emmanuele, could you handle this? Thanks, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Thu, 2010-06-10 at 13:24 +0200, Andre Klapper wrote:
[snip]
The following modules are affected (list not necessarily complete):
[snip]
Also, avahi is an external dependency, and its tarball has an avahi-ui
library, which is therefore also implicitly blessed. It has not yet been
ported to GTK+-3.0. I don't know if anything in the GNOME release sets
uses avahi-ui, though it's blocking my port of Glom.
I tried to file a ticket about it at avahi.org but couldn't log in.
CCing Lennart instead. The attached patch is one possible fix that works
for me, though I think this would be easier if avahi-ui was a separate
module.
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
From 4f245843c26940fb9cf55c6fdf1af8ca8e91c755 Mon Sep 17 00:00:00 2001
From: Murray Cumming murr...@murrayc.com
Date: Sun, 13 Jun 2010 13:59:58 +0200
Subject: [PATCH] avahi-ui: Use gtk-3.0 instead of gtk-2.0 and become avahi-ui-3.0.
* avahi-ui.pc.in: Rename to avahi-ui-3.0.pc.in and update it.
* configure.ac: Check for gtk-3.0 instead of gtk-2.0,
update the .pc.in mention and rename the (already-versioned)
variables.
* Makefile.am: Change for the renamed .pc file.
* avahi-ui/Makefile.am: Change the shared library name to
libavahi-ui-3.0 and change the installed headers location to
avahi-ui-3.0
* avahi-discover-standalone/Makefile.am: Adapt.
---
Makefile.am |8
avahi-discover-standalone/Makefile.am |4 ++--
avahi-ui-3.0.pc.in| 11 +++
avahi-ui.pc.in| 11 ---
avahi-ui/Makefile.am | 26 +-
configure.ac |8
6 files changed, 34 insertions(+), 34 deletions(-)
create mode 100644 avahi-ui-3.0.pc.in
delete mode 100644 avahi-ui.pc.in
diff --git a/Makefile.am b/Makefile.am
index c19e72c..b21bee7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,7 +49,7 @@ EXTRA_DIST = \
avahi-ui-sharp.pc.in \
avahi-compat-libdns_sd.pc.in \
avahi-compat-howl.pc.in \
- avahi-ui.pc.in \
+ avahi-ui-3.0.pc.in \
doxygen_to_devhelp.xsl
SUBDIRS = \
@@ -245,14 +245,14 @@ endif
if HAVE_GTK
if HAVE_DBUS
-pkgconfig_DATA += avahi-ui.pc
+pkgconfig_DATA += avahi-ui-3.0.pc
-avahi-ui.pc: avahi-ui.pc.in
+avahi-ui-3.0.pc: avahi-ui-3.0.pc.in
sed -e 's,@prefix\@,$(prefix),g' \
-e 's,@libdir\@,$(libdir),g' \
-e 's,@PACKAGE_VERSION\@,$(PACKAGE_VERSION),g' $ $@
-CLEANFILES += avahi-ui.pc
+CLEANFILES += avahi-ui-3.0.pc
endif
endif
diff --git a/avahi-discover-standalone/Makefile.am b/avahi-discover-standalone/Makefile.am
index 133ff4d..671f67a 100644
--- a/avahi-discover-standalone/Makefile.am
+++ b/avahi-discover-standalone/Makefile.am
@@ -35,7 +35,7 @@ avahi_discover_standalone_SOURCES = \
avahi_discover_standalone_CFLAGS = \
$(AM_CFLAGS) \
- $(GLIB20_CFLAGS) $(GTK20_CFLAGS) \
+ $(GLIB20_CFLAGS) $(GTK30_CFLAGS) \
-DAVAHI_INTERFACES_DIR=\$(interfacesdir)\
avahi_discover_standalone_LDADD = \
@@ -43,7 +43,7 @@ avahi_discover_standalone_LDADD = \
../avahi-common/libavahi-common.la \
../avahi-glib/libavahi-glib.la \
../avahi-core/libavahi-core.la \
- $(GLIB20_LIBS) $(GTK20_LIBS)
+ $(GLIB20_LIBS) $(GTK30_LIBS)
interfaces_DATA = $(interfaces)
diff --git a/avahi-ui-3.0.pc.in b/avahi-ui-3.0.pc.in
new file mode 100644
index 000..43a1719
--- /dev/null
+++ b/avahi-ui-3.0.pc.in
@@ -0,0 +1,11 @@
+pref...@prefix@
+exec_prefix=${prefix}
+libd...@libdir@
+includedir=${prefix}/include
+
+Name: avahi-ui
+Description: Avahi Multicast DNS Responder (Common GTK UI support)
+Requires: gtk+-3.0 avahi-client avahi-glib
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lavahi-ui-3.0
+Cflags: -D_REENTRANT -I${includedir}
diff --git a/avahi-ui.pc.in b/avahi-ui.pc.in
deleted file mode 100644
index ca9c2ef..000
--- a/avahi-ui.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-pref...@prefix@
-exec_prefix=${prefix}
-libd...@libdir@
-includedir=${prefix}/include
-
-Name: avahi-ui
-Description: Avahi Multicast DNS Responder (Common GTK UI support)
-Requires: gtk+-2.0 avahi-client avahi-glib
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -lavahi-ui
-Cflags: -D_REENTRANT -I${includedir}
diff --git a/avahi-ui/Makefile.am b/avahi-ui/Makefile.am
index 6dbbd24..d5ae636 100644
--- a/avahi-ui/Makefile.am
+++ b/avahi-ui/Makefile.am
@@ -34,29 +34,29 @@ AM_CFLAGS += -DGNOMELOCALEDIR=\$(datadir)/locale\
if HAVE_DBUS
if HAVE_GLIB
-avahiincludedir=$(includedir)/avahi-ui
+avahiincludedir=$(includedir)/avahi-ui-3.0
avahiinclude_HEADERS = \
avahi-ui.h
lib_LTLIBRARIES = \
- libavahi-ui.la
+ libavahi-ui-3.0.la
-libavahi_ui_la_SOURCES = \
+libavahi_ui_3_0_la_SOURCES = \
avahi-ui.h avahi-ui.c
-libavahi_ui_la_CFLAGS = $(AM_CFLAGS) $(GTK20_CFLAGS)
-libavahi_ui_la_LIBADD = $(AM_LDADD) ../avahi-common/libavahi-common.la ../avahi-client/libavahi-client.la ../avahi-glib/libavahi-glib.la $(GTK20_LIBS)
-libavahi_ui_la_LDFLAGS = $(AM_LDFLAGS) -version-info $(LIBAVAHI_UI_VERSION_INFO)
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) https://bugzilla.gnome.org/show_bug.cgi?id=618473 Emmanuele could do a release. - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, Jun 12, 2010 at 5:49 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. I can't speak for Xavier, but some of us maintain applications for which the latest version is commonly in demand from users of older distros, and maintaining a separate branch is a fair amount of work if you're the only one doing testing, QA, and release management. There's no way I can consider dropping GTK2 compatibility from Tomboy for the next year or so, for example. I don't have the resources to maintain two versions. A separate but related issue is that unless somebody plans to update gtk-sharp, Tomboy may not be GTK3 compatible this cycle (I don't know off-hand what parts of gtk-sharp may be incompatible with GTK3). Do other non-C apps have similar issues, or is this just a problem with the Mono bindings? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le 12/06/10 14:49, Bastien Nocera a écrit : On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) https://bugzilla.gnome.org/show_bug.cgi?id=618473 Emmanuele could do a release. - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3, and if we can't build Empathy with GTK2 then they'll just keep Empathy 2.30.x... tbh I think that's a bad decision from Ubuntu, but it would be really sad to not ship the latest empathy... But I guess if the whole GNOME 2.32 depends on GTK3 then they'll change their mind. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, 2010-06-12 at 17:31 +0200, Xavier Claessens wrote: Le 12/06/10 14:49, Bastien Nocera a écrit : On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) https://bugzilla.gnome.org/show_bug.cgi?id=618473 Emmanuele could do a release. - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3, and if we can't build Empathy with GTK2 then they'll just keep Empathy 2.30.x... tbh I think that's a bad decision from Ubuntu, but it would be really sad to not ship the latest empathy... And you're telling me that your decision on keeping a GTK+ 2.x version is based on one distributor's dubious decision? GNOME 3.x will be based on GTK+ 3.x. But I guess if the whole GNOME 2.32 depends on GTK3 then they'll change their mind. I know that all my modules will. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, Jun 12, 2010 at 7:36 PM, Michael Terry m...@mterry.name wrote: On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome Hmm, a Canonical employee approached me just the other day. He was told not to include in Maverick packages that depended on GTK3, and wanted to check with me that Tomboy would remain GTK2-compatible this cycle, so that he could get our latest unstable releases into Maverick. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 libclutter-gtk 1.0 will only support gtk+ 3.0 - and leave gtk+ 2.0 support to the 0.10 series. - libunique-3 (or drop gtk2 compatibility and use GtkApplication) with my libunique maintainer hat on, I strongly suggest people to migrate to gtk+ 3.0 and GtkApplication. I'm making sure the feature set is equivalent, and will write a unique-to-gtk porting guide to be included in gtk+'s API reference. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, Jun 11, 2010 at 6:36 PM, Xavier Claessens xclae...@gmail.com wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libchamplain-gtk-3 Probably libchamplain-0.8 will be GTK+3 compliant (well, it acutally needs only changing the pk-config checks ;), but needs a GTK+3 libsoup-gnome, which in turn may be blocked by libproxy which uses GConf to store the proxy configuration (which probably waits for a resolution of the system wide GSettings keys) and that should be all. I don't know if any of the empathy devs are on the libchamplain list, but I'll post there some of my issues with that (as not to spam the d-d-l more) Regards, -- Łukasz [DeeJay1] Jernaś ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) I think we should just port to GtkApplication. I've filed: https://bugzilla.gnome.org/show_bug.cgi?id=621339 It would be nice if GtkApplication was also available in GTK+ 2.21.x though, it would ease the porting effort. - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, Jun 11, 2010 at 12:36 PM, Xavier Claessens xclae...@gmail.com wrote: To make Empathy build with gtk3 we need: - libcanberra-gtk-3 This is done in libcanberra git. I'll ask Lennart to roll a tarball for 2.31.4. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 10 June 2010 12:24, Andre Klapper ak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3 = 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Richard Hughes wrote: On 10 June 2010 12:24, Andre Klapper ak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3 = 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. Yeah, the angry release team mob is already on this :) Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Thu, 2010-06-10 at 13:42 +0200, Frederic Peters wrote: Richard Hughes wrote: On 10 June 2010 12:24, Andre Klapper ak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3 = 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. Yeah, the angry release team mob is already on this :) Just an FYI, the code for this exists in the gnome3 branch of gtk-engines and at least Clearlooks works properly. The others at the very least compile. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
