I’ve been meaning to post this for a long time, and finally decided that maybe now would be a good time to do it.
I’m really pleased that a lot of projects are now using libsexy. This is awesome stuff, and I want to thank people for making use of this library.
However, the one thing that bothers me is that everybody seems to think libsexy is like libegg. I’m seeing projects bundle libsexy directly in their apps or taking a piece of libsexy, renaming it, and sticking it in their tree. Guys, this lib is not meant to be used like this. It’s a formal library, and it’s pretty standard. Every distribution that ships notification-daemon or xchat-gnome also ships libsexy, so you can pretty much guarantee it’ll be there. I know it’s not part of the GNOME desktop, but given that so many apps are using it, I’d rather see it become a blessed dependency or a configure-time option than bundled.
Shipping a copy or fork of libsexy into your apps has the following problems:
- Upgrades to libsexy proper won’t fix bugs or enhance the applications that are using it.
- People end up modifying their forks and never send patches upstream.
- Some projects end up copying from other projects and never even realize they’re using libsexy in the first place.
It also confuses me that some projects end up rewriting their own versions of some of these widgets instead of using libsexy’s. For example, Evolution has EIconEntry, which is like SexyIconEntry except that it uses an HBox and some style tricks instead of being an actual GtkEntry. Let’s standardize! 🙂
So this is a call-out to the developers of Rhythmbox, Last-exit, xchat, gedit, and any other projects in any way making use of libsexy incorrectly. Please fix your apps so we can have an actual shared library that can be properly upgraded.
And to the Epiphany and Evolution projects, is there any reason anymore to not use SexyIconEntry instead of a custom HBox-based solution? A while back, I was told that the motivation was due to some rendering and usability bugs in SexyIconEntry that have since been fixed, so this is a good time to find out if there’s anything more that I could do to get you guys to use it.
Thanks.
Update: Last-exit now links against the system’s libsexy. Thanks to Brandon Hale for his work on this 🙂
If SexyIconEntry is that great, why don’t we move it into GTK+? 🙂
I’ve thought about using libsexy in my application, and have ended up not using it because Mono bindings aren’t available on my platform. I do not want to p/invoke to a lib that may or may not be installed, because it adds extra packaging overhead, which I do not want to do. The easiest way around this is to package and distribute it with the app, which as you suggest in your blog entry is wrong for very good reasons.
It makes sense that this type of functionality should be in gtk, rather than as an add-on. I got the feeling, that when libsexy came out, it was more to prove the concept, and then make it available in gtk, rather than develop yet another dependency that a lot of applications will end up using.
I’m sure this question may have come up before, but pushing in this direction will stop people from shipping copies or forks of it around, let them use the native gtk implementation, which will be consistent over the whole gtk platform.
Do you have any thoughts about getting libsexy added to gtk.
libsexy is nice, but you should fix the pkg-config file. Libs and Cflags are not used properly, they should only contain -lsexy and -I${includedir}. You should use Requires (for dependencies needed for dynamical linking) and Requires.private (for dependencies needed for statical linking).
Besided from that, I agree with you.
It’s a horror for distros, if they have to fix a gazillion apps, if a bug in libsexy is detected.
I’m very much in favor of moving the libsexy components to GTK+. However, a lot of what libsexy does could be considered “hacks” as they extend existing widgets in ways that they really weren’t meant to be extended. The proper path is to fix up the widgets, but that’s potentially dangerous for backwards-compatibility. I’m thinking that the best course of action is to have people use libsexy for now and then discuss ways of fixing up GTK for GTK+ 3.0.
Michael: I don’t think this has been pointed out to me (or I’ve missed it). I’d be glad to get this fixed up.
yes, why don’t integrate entire libsexy into gtk?
anonim: I answered that.
Fedora doesn’t ship libsexy, and at least as far as Rawhide (F7 test) they still are shipping a patch that strips libsexy out of the notification-daemon.
Maybe they’ll rethink that when Extras is merged in F7.
Rhythmbox will use the system’s version of libsexy if it is available. However, there are enough systems that don’t have libsexy available by default that it is necessary to use a private copy… or not use it at all.
> then discuss ways of fixing up GTK for GTK+ 3.0
I think the time to start discussing this is now. You should file everything libsexy provides as feature requests against gtk+.
Rhythmbox uses the shared library if it’s present when RB is compiled, and only uses the internal copy as a fallback. The reason we have it as a fallback was that at the time, virtually none on the released distros had libsexy, only the in-development versions – so if we wanted to use it, it was basically a choice between having a fallback copy, or falling back to the standard GTK widgets.
If most distros now ship it, we could probably remove the fallback.
Jon, James: Oh, I wasn’t aware of this. This makes a lot of sense. My understanding was that most distros now ship libsexy, though I guess FC7 doesn’t. Huh. Given how popular Rhythmbox is, I bet the distros will bundle it if it’s a dependency. Still, using the system’s libsexy takes care of my concerns. Thanks for clearing that up 🙂
Debian Etch and Ubuntu Edgy ship libsexy. It also seems to be a dependency of the gnome-core, rhythmbox and xchat packages (but not gedit).
(gah three tries on the evil captcha to write this)
Consider writing a plugin to glade 😀
If a glade/libglade plugin exists and is installed, then
the libsexy widgets will show up in glade… I’m sure this
would help encourage people to use libsexy as a widget kit
proper instead of just a heap of code 😉