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: bumping telepathy-glib's external dependencies for 2.32
Le mercredi 26 mai 2010 à 10:26 +0200, Guillaume Desmottes a écrit : Le mercredi 21 avril 2010 à 09:11 +0200, Guillaume Desmottes a écrit : Le jeudi 01 avril 2010 à 11:01 +0200, Guillaume Desmottes a écrit : Hi, I plan to use in Empathy new API from telepathy-glib so will have to dump the external dependency to 0.11. This will be needed for new features and factor out code from Empathy to tp-glib. I'd like to bump to 0.11.3. This will allow me to fix #579813. Actually I plan to use latest 0.11.x releases during this cycle. We plan to release tp-glib 0.12.0 (stable branch) in time for GNOME 2.32 so distributions will ship this version. telepathy-glib 0.11.6 has been released [1] yesterday. I plan to use it soon in Empathy as it introduces lot of new API making Empathy simpler. I updated the wiki and jhbuild to 0.11.7 as Empathy is going to use it. G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ 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
