GNOME Bugzilla – Bug 618475
Port to GTK+ 3.0
Last modified: 2010-06-26 18:07:22 UTC
So that symbolic icons keep on working.
Created attachment 160921 [details] [review] Port to GTK+ 3.0 Rename library librsvg-3, and other changes for GTK+ 3.0 support.
There appear to be no code changes in librsvg required to compile against gtk 3.0. Wouldn't it make more sense to keep the ability to compile against gtk 2.0, and just add a --with-gtk-version=2|3 and adapt the library version accordingly?
There are 2 problems. There *could* be changes necessary in the future, and it would be easier for distributions to build as two separate packages, just like they build gtk+ 2.x and gtk+ 3.x separately. In the end, it's really up to the maintainer whether to have 2 different versions, or just the one with a --gtk-version=X. I think the former is more maintainable in the long run, especially with git making it easy to cherry-pick between branches.
I agree that it's up to the maintainer. I disagree however that a separate branch is better. If there are code changes, it's probably easier to #if GTK_CHECK_VERSION (3, 0, 0) them. Having separate branches means that you need to roll two tarballs, while one branch means you can build both from the same tarball.
(In reply to comment #4) > I agree that it's up to the maintainer. I disagree however that a separate > branch is better. If there are code changes, it's probably easier to #if > GTK_CHECK_VERSION (3, 0, 0) them. Having separate branches means that you need > to roll two tarballs, while one branch means you can build both from the same > tarball. But you'll need to build twice, and it would make the work harder for packagers.
I am inclining to maintain two branches for the benefits of distribution's packagers. I am just curious the life cycle of GTK+-2.x. If the cycle is quite long like GTK+1.x, I will give up the maintenance of librsg-2 branch at some time in the future. But I will manage to maintain it until that time.
gtk 2.x is expected to have a long afterlife, yes.
Hiroyuki, it would be great to have a librsvg release that supports gtk3, so people can start porting to gtk3 without loosing svg support.
(In reply to comment #5) > (In reply to comment #4) > > I agree that it's up to the maintainer. I disagree however that a separate > > branch is better. If there are code changes, it's probably easier to #if > > GTK_CHECK_VERSION (3, 0, 0) them. Having separate branches means that you need > > to roll two tarballs, while one branch means you can build both from the same > > tarball. > > But you'll need to build twice, and it would make the work harder for > packagers. I don't see how building librsvg-2 package from librsvg-2-x.y.z.tar.bz2 and librsvg-3 package from librsvg-3-x.y.z.tar.bz2 tarballs is any problem? Whether the -2 and -3 tarballs happen to be identical copies of one another, or different, should make not difference to the packaging effort, right? Some packaging systems (.deb) even allow building multiple packages from the _same_ tarballs. (In reply to comment #6) > I am inclining to maintain two branches for the benefits of distribution's > packagers. > > I am just curious the life cycle of GTK+-2.x. If the cycle is quite long like > GTK+1.x, I will give up the maintenance of librsg-2 branch at some time in the > future. But I will manage to maintain it until that time. My point was that it's possible to deliver both libraries from the same code, reducing maintenance effort (and also ensure that -2 branch doesn't become dormant by accident). I'd be prepared to produce a patch that just adds a --with-gtk=2.0|3.0 configure arg and sets up library name and install paths accordingly.
Separate tarballs will make it harder because we don't want to have two _libraries_, we just want two modules.
(In reply to comment #10) > Separate tarballs will make it harder because we don't want to have two > _libraries_, we just want two modules. We want two libraries: $ ldd /usr/lib64/librsvg-2.so.2 | grep gdk libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x0000003398400000)
ugh, indeed ignore me
I read the log of GTK+ meeting on 2010-06-08. < mclasen> do we have a volunteer to work on standalone gdk-pixbuf ? < ebassi> mclasen: I'll talk with my manager and see if I can get team time to work on it (and fix it, while we're at it) < ebassi> it's something we wanted to do anyway < mclasen> nice, thanks When gdk-pixbuf is independent of GTK+, do we still need two librsvg libraries on system?
> When gdk-pixbuf is independent of GTK+, do we still need two librsvg libraries > on system? We will still need to separate modules. But we can get away with a single library.
But...I would not bet the farm on gdk-pixbuf actually getting split out for 3.0 yet.
Ah, I see. Then I would like to wait for chpe's patch.
I pushed a patch for this to the "dual-gtk" branch. It seems to install everything find for gtk 2.0; it's untested for gtk 3.0 since I don't have that.
I'll give it a try
Seems to work as expected here. Passed "--with-gtk=3.0" to configure, and it got built against gdk-pixbuf 3.0 and GTK+ 3.0
Thank you very much, Christian! Merged into master. http://git.gnome.org/browse/librsvg/commit/?id=9a7292daf337e4da4eacf62edb45f34c28d11df2
Reopening this. I have now done the work to split out gdk-pixbuf, so we should revisit this. You don't need to build twice anymore, a single, separate gdk-pixbuf version is now shared between gtk2, gtk3, clutter, etc. One thing to notice: the loaders are now installed in $libdir/gdk-pixbuf-2.0/2.10.0/loaders Sorry for the inconvenience...
Continued on bug 622790. *** This bug has been marked as a duplicate of bug 622790 ***