libsexy v0.1.11 released

We just put out a new bugfix release of libsexy. A number of important SexyUrlLabel changes went in, so please upgrade, as notification-daemon and xchat-gnome both use this.

As always, the latest version is available on the libsexy page or in the download directory.

Release notes:

  • Fix a typo in SexyUrlLabel that was causing the widget to never be marked as unmapped, which prevented it from re-mapping the event window when the widget was shown again. (Bugs #364030 and #353946)
  • Fixed the cursors to properly indicate whether the text was selectable.
  • Get rid of the unused SexyTooltipPriv structure to fix building on Solaris. (Bug #378066)
  • Remove some debug output from SexyIconEntry and SexyTreeView. (Bug #355129)

libsexy is not libegg

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.


Update: Last-exit now links against the system’s libsexy. Thanks to Brandon Hale for his work on this 🙂

libsexy v0.1.9 released

libsexy, libsexymm, and sexy-python 0.1.9 have been released.

libsexy v0.1.9 is just bug fix release (but a good one), containing the following fixes:

  • Fixed a bug where the cursor position in a SexySpellEntry would change if the position was at the end of the entry and word was replaced.
  • Fixed a few enchant-related bugs in SexySpellEntry.
  • Fixed our GModule loading for enchant to let glib figure out the proper file extension, rather than hard-coding “.so”.
  • Fixed some uninitialized variables when creating the icon windows for SexyIconEntry that were causing valgrind to complain. Patch by Benjamin Otte. (Bug #349701)
  • Fixed a bug in SexyIconEntry where the caret would be invisible at the start of the entry when no icon was shown. Patch by Ed Catmur. (Bug #353671)
  • Fixed a bug with SexyToolTip positioning in treeviews without headers where the tooltips would immediately disappear when shown at the bottom of the screen. (Bug #333424)
  • Fixed a linking bug when building on win32. Patch by Steffen Eschenbacher. (Bug #351796)

libsexymm and sexy-python contain license updates and were updated to work with libsexy v0.1.9. Both bindings claimed to be GPL, while they were intended to be LGPL. Sorry for the confusion, packagers 🙂

Scroll to Top