A long time ago I started work to port my rudimentary treeview hack from its TreeViewHints python implementation in Quod Libet to a much more solid inplace-tooltips implementation in gtk+ itself. Inplace-tooltips are the little tips that appear as you move your cursor over items that aren't fully visible, and often appear immediately instead of after a hover delay.

For whatever reasons the patch has neither been nurtured and accepted nor denied, and has languished for most of the 19 months since I first filed the feature request. I personally suspect things varying from confusion over the term tooltips being in the name to malevolent negligence, but claiming either of those doesn't help the situation anyway.

Eight months ago I found a much better approach to it, which wrangled out some superficial bugs for free, and updated the patch. Finally over the past two weeks, I found that Debian's gtk+ package had changed its build procedure, and this time was able to figure out how to integrate my patch. Wow, what a difference it makes to use it full time. In under two weeks I'd found and filled some important gaps in my initial implementations, including fixing the tip's position when a tree is scrolled horizontally.

But building my own Debian packages comes at a price. Not only does it take significant time to build the packages, there are three options each with disadvantages.

• Apply just the code patch

By applying just the code patch I get all the behavior changes I want...so long as I don't run a package update. If I run a package update, the original libgtk2.0-0 package takes precedence over my package, and offers to reinstall.

• Also apply a debian revision suffix

When Ubuntu makes packages, they apply a suffix to ensure that Debian's packages of the same version do not override theirs, but a newer Debian package can (so long as all dependencies are satisfied). This prevents the official package from overwriting my patched packages. However doing this causes the policy of my package to move past the testing archive and into the limbo which pulls in packages from unstable. It also requires I install some auxiliary packages due to tight version dependencies in the core gtk+ related packages.

• Apply an epoch

An epoch is a special version indication that would let me continue to call my package by the same version the rest of gtk+ does, but tell the package management system it's newer than the official package. Assuming Debian never needs to bump their epoch, this would insulate me from the testing–>unstable bump, as my packages would always be even newer than the ones in unstable. However because of that it would be much harder to track when it was time to upgrade my own packages.

Currently I gave up on the first, and am still trying the second. I've run into one major hitch: aptitude doesn't work how I want it to. In particular I'm running with my suffixed package version 2.12.5-2+0mu, and unstable now has 2.12.7-1:

% apt-cache policy libgtk2.0-0
libgtk2.0-0:
  Installed: 2.12.5-2+0mu
  Candidate: 2.12.7-1
  Version table:
     2.12.7-1 0
        601 http://http.us.debian.org unstable/main Packages
 *** 2.12.5-2+0mu 0
        100 /var/lib/dpkg/status
     2.12.5-2 0
        900 http://http.us.debian.org testing/main Packages

Because I'm beyond testing (which I have as my default), apt and aptitude want to attempt to keep me at unstable (my fallback) because it appears that's where I was before the update. I'm not ready to make this leap; I want to make it when 2.12.7 reaches testing. So I employ the next trick in the book: hold.

Hold is supposed to tell aptitude to ignore this package during normal upgrades until I explicitly tell it to install a newer version. But it just doesn't work. If you visit aptitude's bug page and search for hold it becomes obvious that there have been lots of problems with hold, and most of them are still unresolved. Most of them have to do with synchronizing aptitude's list of holds with dselect (and apt's) list. But if that were all, I could work around it. Instead aptitude doesn't even follow its own holds:

% dpkg --get-selections | egrep 'gtk2-engines-pixbuf|libgtk2.0-0|libgtk2.0-dev'
gtk2-engines-pixbuf				hold
libgtk2.0-0					hold
libgtk2.0-dev					hold
% sudo aptitude unhold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev
[...]
% sudo aptitude hold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev  
[...]
% sudo aptitude safe-upgrade
[...]
The following packages will be upgraded:
  gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev 
3 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 6061kB of archives. After unpacking 12.3kB will be used.
Do you want to continue? [Y/n/?] n
Abort.

Now that I've seen this sloppy behavior among others, and seen just how many long standing bugs there are against aptitude, I think it's time to go back to dselect, apt-get, and deborphan. Too bad; aptitude seemed like a good idea at the time.

My favorite Japanese input method for gtk+, im-ja, broke when I updated to Debian's gtk+ 2.10 packages. Since there's no upstream activity to speak of (much less new packages), and I can't seem to find this on the web anywhere else, here's the solution I eventually found. No doubt there's a better one out there that updates the package to use the new debhelper support for gtkimmodules to create this file, but I made mine by hand:

% cat /usr/lib/gtk-2.0/2.10.0/immodule-files.d/imja.immodules 
# edited by hand
"/usr/lib/gtk-2.0/2.4.0/immodules/im-ja.so"
"im-ja" "Japanese" "gtk+" "/usr/share/locale" "ja"

I had tried compiling a new version of the existing package that would go into the 2.10.0 immodules folder, but that didn't help. When I wired that version up with the slight mode to the above file, it crashed applications that tried to use it. But the original im-ja package is still kicking!

Just dropping a quick note here because Independence Week (I took a few extra vacation days after the 4th) gave me time to start more projects than I normally do. And now I'm really busy from them. So in that vein, three quick notes.

The first is a really cool patch to GTK+ which is the beginnings Inplace-Tooltips — the next generation version of my TreeViewHints hack. I have an Ogg Theora screencast of what it can already do in Ex Falso (with TreeViewHints disabled), and am hoping to make a MNG in case it's smaller. I think the hard parts of this battle are making sure the behavior is perfect, that it doesn't leak references, and getting the decision makers to recognize its importance.

The second is a request to those holding copyright interests in GPL-licensed GStreamer-using projects Fluendo has asked to consider relicensing under terms compatible with plugins with which they wouldn't otherwise be compatible. Don't. You chose to license your code under the GPL for a reason. You are being asked to weaken your support for Free Software for commercial reasons, and being offered only the opportunity to be distributed with a particular Linux distribution. You are being asked to trade your belief in Freedom for an imaginary increase in your user base. Freedom is worth much more than that. Stand up for your beliefs and don't worry about people using encumbered formats in distributions that can't handle this a better way.

The last is I've started learning Cairo and have put together the beginnings of a Go client (so far it's just the board display). Cairo is a real treat to work with, but there's not any good introductory documentation. I received a great explanation of the basics just last night from Carl Worth and I hope to put it and the rest of what I've learned into a series of blog posts, and later perhaps a three-in-one tutorial of PyGTK gobjects and cairo.