Shallow Thoughts

Sometimes a horrible hack is the best solution (and building gtk on Tiger)

Dave has been fighting for I don't know how many weeks trying to get a buildable set of gtk libraries installed on his Mac.

He doesn't need them to build GIMP -- the GIMP on OS X project (split off from Wilber Loves Apple) provides binaries complete with all the libraries needed. Alas, it's just a binary package with no development headers, so if you want to build any other gtk packages, like pho, or maybe some GIMP plug-ins, you're in for a much longer adventure.

Mac Ports used to make that easy, but the Ports version of gtk2 doesn't build on OS X "Tiger". It's a long story and I don't (want to) know all the hairy details, but this weekend he finally gave up on it and began downloading all the gtk2 packages and dependencies (cairo, pango, bonobo, atk etc.) from their various project sites.

Oddly enough, building them went much more smoothly than Ports had, and after a little twiddling of --disable flags in configure and a lot of waiting, he had most of the libraries built. Even gtk2 itself! Except ... gtk2's make install failed.

Seems that although gtk is configured to disable building docs by default (configure --help shows a --enable-gtk-doc option), nevertheless make install calls something called gtkdoc-rebase from a lot of the subdirectories. And gtkdoc-rebase doesn't exist, since it wasn't ever built. So the whole make install process fails at that point -- after installing the libraries but before telling pkg-config that gtk-2.0 is indeed present.

After twiddling configure dependencies all day, Dave was getting frustrated. "How do I configure it to really disable docs, so it won't try to run this gtkdoc-rebase thing I don't have?"

I was in the middle of a timed quiz for a class I'm taking. "I have no idea. You'd think they'd check for that. Um ... all you need is for gtkdoc-rebase to return success, right? What if you make a script somewhere in your path that contains nothing but a shebang line, #! /bin/sh? It's a horrible hack, but ..."

"Horrible hacks R us!" he exclaimed, and created the script. 10 minutes later, he had gtk-2.0 installed, pkg-config notified and pho built.

Sometimes horrible hacks are the best.

The gtk2 package list

Incidentally, for anyone trying to accomplish the same thing, the packages he needed to download were:

pgk-config gettext glib pango atk jpeg jasper libpng tiff pixman freetype libxml fontconfig cairo gtk2

and he had to configure gtk2 with --disable-cups (because it introduced other errors, not because of CUPS itself). The trickiest dependency was atk, because it wasn't in the place that gtk.org points to and it wasn't on its own project site either; he eventually found it by poking around on the gnome ftp site.

Tags: hack, gtk, OS X
[ 20:44 Dec 14, 2008    More programming | permalink to this entry ]

Pho 0.9.6 finally released!

Pho 0.9.6-pre3 has been working great for me for about a month, and I've been trying to find the time to do a release. I finally managed it this weekend, after making a final tweak to change the default PHO_REMOTE command from gimp-remote to gimp since gimp-remote is obsolete and is no longer built by default.

The big changes from 0.9.5 are Keywords mode, slideshow mode, the new PHO_REMOTE environment variable, swapping -f and -F, and a bunch of performance work and minor bug fixing.

I built deb packages for Ubuntu (Hardy, but they should work on Intrepid too) and Debian (Etch), as well as the usual source tarball, and they're available at the usual place:

http://shallowsky.com/software/pho.

Tags: software, hacking, pho, image viewer
[ 17:11 Nov 09, 2008    More programming | permalink to this entry ]

Requesting no window decorations (and moonroot 0.4)

Someone on #openbox this morning wanted help in bringing up a window without decorations -- no titlebar or window borders.

Afterward, Mikael commented that the app should really be coded not to have borders in the first place.

Me: You can do that?

Turns out it's not a standard ICCCM request, but one that mwm introduced, MWM_HINTS_DECORATIONS. Mikael pointed me to the urxvt source as an example of an app that uses it.

My own need was more modest: my little moonroot Xlib program that draws the moon at approximately its current phase. Since the code is a lot simpler than urxvt, perhaps the new version, moonroot 0.4, will be useful as an example for someone (it's also an example of how to use the X Shape extension for making non-rectangular windows).

Tags: programming, xlib, astronomy, window managers
[ 11:06 Oct 20, 2008    More programming | permalink to this entry ]

New Pho 0.9.6-pre3

I've released Pho 0.9.6-pre3. The only change is to fix a sporadic bug where pho would sometimes jump back to the first image after deleting the last one, rather than backing up to the next-to-last image. I was never able to reproduce the bug reliably, but I cleaned up the image list next/prev code quite a bit and haven't seen the bug since then. I'd appreciate having a few testers exercising this code as much as possible.

Otherwise pho is looking pretty solid for a 0.9.6 release.

Tags: software, hacking, pho, image viewer
[ 09:57 Oct 02, 2008    More programming | permalink to this entry ]

Pho 0.9.6-pre1

I've been using my pre-released 0.9.6-pre1 version of pho, my image viewer, for ages, now, and it's been working fine. I keep wanting to release it, but there were a couple of minor bugs that irritated me and I hadn't had time to track down. Tonight, I finally got caught up with my backlog and found myself with a few extra minutes to spare, and fixed the last two known bugs. Quick, time to release before I discover anything else!

(There were a couple other features I was hoping to implement -- multiple external commands, parsing a .phorc file, and having Keywords mode read and write the Keywords file itself -- but none of those is terribly important and they can wait.)

It's only a -pre release, but I'm not going to have a long protracted set of betas this time. 0.9.6-pre1 is very usable, and I'm finding Keywords mode to be awfully useful for classifying my mountain of back photos.

So, pho users, give it a try and let me know if you see any bugs! It's my hope to release the real 0.9.6 in a week or two, if nobody finds any monstrous bugs in the meantime.

Get Pho here.

[ 20:30 Aug 11, 2008    More programming | permalink to this entry ]

Crikey in Python, and generating key events with XTest

A user on the One Laptop Per Child (OLPC, also known as the XO) platform wrote to ask me how to use crikey on that platform.

There are two stages to getting crikey running on a new platform:

1. Build it, and
2. Figure out how to make a key run a specific program.

The crikey page contains instructions I've collected for binding keys in various window managers, since that's usually the hard part. On normal Linux machines the first step is normally no problem. But apparently the OLPC comes with gcc but without make or the X header files. (Not too surprising: it's not a machine aimed at developers and I assume most people developing for the machine cross-compile from a more capable Linux box.)

We're still working on that (if my correspondant gets it working, I'll post the instructions), but while I was googling for information about the OLPC's X environment I stumbled upon a library I didn't know existed: python-xlib. It turns out it's possible to do most or all of what crikey does from Python. The OLPC is Python based; if I could write crikey in Python, it might solve the problem. So I whipped up a little key event generating script as a test.

Unfortunately, it didn't solve the OLPC problem (they don't include python-xlib on the machine either) but it was a fun exercises, and might be useful as an example of how to generate key events in python-xlib. It supports both event generating methods: the X Test extension and XSendEvent. Here's the script: /pykey-0.1.

But while I was debugging the X Test code, I had to solve a bug that I didn't remember ever solving in the C version of crikey. Sure enough, it needed the same fix I'd had to do in the python version. Two fixes, actually. First, when you send a fake key event through XTest, there's no way to specify a shift mask. So if you need a shifted character like A, you have to send KeyPress Shift, KeyPress a. But if that's all you send, XTest on some systems does exactly what the real key would do if held down and never released: it autorepeats. (But only for a little while, not forever. Go figure.)

So the real answer is to send KeyPress Shift, KeyPress a, KeyRelease a, KeyRelease Shift. Then everything works nicely. I've updated crikey accordingly and released version 0.7 (though since XTest isn't used by default, most users won't see any change from 0.6). In the XSendEvent case, crikey still doesn't send the KeyRelease event -- because some systems actually see it as another KeyPress. (Hey, what fun would computers be if they were consistent and always predictable, huh?)

Both C and Python versions are linked off the crikey page.

Tags: programming, crikey, X11, python
[ 14:50 May 25, 2008    More programming | permalink to this entry ]

Setting app name and class in Xlib

I was looking at Dave's little phase-of-the-moon Mac application, and got the urge to play with moonroot, the little xlib ditty I wrote several years ago to put a moon (showing the right phase) on the desktop.

I fired it up, and got the nice moon-shaped window ... but with a titlebar. I didn't want that! Figuring out how to get rid of the titlebar in openbox was easy, just

<application name="moonroot">
    <decor>no</decor>
    <desktop>all</desktop>
</application>

... but it didn't work! A poke with xwininfo showed the likely cause: instead of "moonroot", the window was listed as "Unnamed window". Whoops!

A little poking around revealed three different ways to set "name" for a window: XStoreName, XSetClassHint (which sets both class name and app name), and XSetWMName. Available online documentation on these functions was not very helpful in explaining the differences; fortunately someone hanging out on the openbox channel knew the difference (thanks, Crazy_Hopper). Thus:

• XSetWMName sets a property called XA_NAME which is primarily used to update the window's titlebar. Note that this may be more than the app name (for instance, Firefox puts the title of the current page in the titlebar). To use XSetWMName, you have to set up and populate an XTextProperty structure, which first requires that you set up a string list then run XStringListToTextProperty -- not difficult but it's several annoying steps.
• XStoreName is a shortcut to XSetWMName, a way to set the XA_NAME (titlebar name) in one step.
• XSetClassHint sets two properties at once: a name hint and a class hint. This is the name and class that the window manager uses for directives like suppressing the titlebar.

I didn't see much in the way of example code for what an app ought to do with these, so I'll post mine here:

    char* appname;
    XClassHint* classHint;
[ ... ]
    if (argv && argc > 1)
        appname = basename(argv[0]);
    else
        appname = "moonroot";

    /* set the titlebar name */
    XStoreName(dpy, win, appname);

    /* set the name and class hints for the window manager to use */
    classHint = XAllocClassHint();
    if (classHint) {
        classHint->res_name = appname;
        classHint->res_class = "MoonRoot";
    }
    XSetClassHint(dpy, win, classHint);
    XFree(classHint);

And if anyone is interested in my silly moon program, it's at moonroot-0.3.tar.gz. moonroot gives you a large moon, moonroot -s gives a smaller one. I'm not terribly happy with its accuracy and wasted too much time today fiddling with it and verifying that it's doing the right time conversions. All I can figure is that the approximation in Meeus' Astronomical Algorithms is way too approximate (it's sometimes off by more than a day) and I should just rewrite all my moon programs to calculate moon phase the hard (and slow) way.

Tags: programming, xlib, astronomy
[ 20:15 Mar 18, 2008    More programming | permalink to this entry ]

PyTopo and PyGTK pixbuf memory leakage

On a recent Mojave desert trip, we tried to follow a minor dirt road that wasn't mapped correctly on any of the maps we had, and eventually had to retrace our steps. Back at the hotel, I fired up my trusty PyTopo on the East Mojave map set and tried to trace the road. But I found that as I scrolled along the road, things got slower and slower until it just wasn't usable any more.

PyTopo was taking up all of my poor laptop's memory. Why? Python is garbage collected -- you're not supposed to have to manage memory explicitly, like freeing pixbufs. I poked around in all the sample code and man pages I had available but couldn't find any pygtk examples that seemed to be doing any explicit freeing.

When we got back to civilization (read: internet access) I did some searching and found the key. It's even in the PyGTK Image FAQ, and there's also some discussion in a mailing list thread from 2003.

Turns out that although Python is supposed to handle its own garbage collection, the Python interpreter doesn't grok the size of a pixbuf object; in particular, it doesn't see the image bits as part of the object's size. So dereferencing lots of pixbuf objects doesn't trigger any "enough memory has been freed that it's time to run the garbage collector" actions.

The solution is easy enough: call gc.collect() explicitly after drawing a map (or any other time a bunch of pixbufs have been dereferenced).

So there's a new version of PyTopo, 0.6 that should run a lot better on small memory machines, plus a new collection format (yet another format from the packaged Topo! map sets) courtesy of Tom Trebisky.

Oh ... in case you're wondering, the ancient USGS maps from Topo! didn't show the road correctly either.

Tags: programming, python, gtk, pygtk
[ 21:21 Oct 12, 2007    More programming | permalink to this entry ]