% tar tvf /var/portage/distfiles/gedit-2.24.2.tar.bz2| grep sexy -rw-r--r-- 0 1000 1000 3091 Nov 9 15:59 gedit-2.24.2/gedit/sexy-icon-entry.h -rw-r--r-- 0 1000 1000 24140 Nov 9 15:59 gedit-2.24.2/gedit/sexy-icon-entry.c
And that's going to stay that way I'd say.
And the reason for that, iirc is that libsexy is not a dependency of gnome. And will never be. This bug, if taken upstream, will probably be marked LATER or CANTFIX or WONTFIX.
gtk+-2.16 will include support for icons in the standard GtkEntry class, or a derivative of it. It doesn't make sense to make gedit depend on the whole of libsexy library when only one small widget class out of it is copied - one that doesn't change in libsexy anymore because gtk+ will take over the job and no-one cares about that bit in libsexy anymore. Also there are plans to release gtk+-2.16 for GNOME-2.26 time in March, instead of in summer for 2.28 time as planned before. So this "bug" might get fixed upstream by gedit-2.26, not gedit-2.28 as it would be otherwise if the gtk+-2.16 for 1Q 2009 goes through (upstream team agreement amongst themselves is being finalized iirc, looking likely).
err, it'd be gedit-2.28 if gtk+-2.16 release in Q1 doesn't go through, not the other way around, of course
Upstream bug for icon support in GtkEntry is http://bugzilla.gnome.org/show_bug.cgi?id=85292
This is going to stay as is. We are not in the business of adding extra larger dependencies when only a small part is used that will get replaced in 4 months if you work with upstream on it instead.
