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.

Thanks.

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 🙂

libsexy 0.1.7 released

I just put out a release of libsexy v0.1.7. It contains a number of fixes to SexySpellEntry, so if you’re doing any work with that or using it in software such as xchat-gnome, you’ll want to upgrade. Full release notes are available. Python and gtkmm bindings are also available at the libsexy site.

On a more humorous note, I’ve been told by a friend that he can no longer visit my blog due to mentions of libsexy causing his proxy to block my site. Anybody else having this issue? 🙂

Spice things up in your relationship with libsexy v0.1.6

libsexy v0.1.6 has just been released, along with libsexymm and sexy-python (mono bindings coming soon). It contains two new widgets, SexyTreeView (a GtkTreeView subclass with support for per-cell tooltips) and SexyTooltip (a tooltip that can have widgets packed into it). It also fixes a few licensing inconsistencies (the header files on a couple files were incorrect) and some bugs.

If you’re using the new notification-daemon, it is advised that you update your copy of libsexy in order to fix a minor visual glitch.

libsexy 0.1.4 released

I just put out a release of libsexy 0.1.4 tonight. It’s a bugfix release that fixes some UTF-8 problems in SexySpellEntry, and also a compile issue some people have had regarding sexy-marshal.h.

Also, libsexy now has a webpage set up! Woot! About time, really. A little directory containing tarballs and a few blog entries just wasn’t enough, as I’ve quickly come to learn by the number of packagers linking to my blog entries 🙂