Shallow Thoughts : tags : gtk

Pytopo 0.8 released

On my last Mojave trip, I spent a lot of the evenings hacking on PyTopo.

I was going to try to stick to OpenStreetMap and other existing mapping applications like TangoGPS, a neat little smartphone app for downloading OpenStreetMap tiles that also runs on the desktop -- but really, there still isn't any mapping app that works well enough for exploring maps when you have no net connection.

In particular, uploading my GPS track logs after a day of mapping, I discovered that Tango really wasn't a good way of exploring them, and I already know Merkaartor, nice as it is for entering new OSM data, isn't very good at working offline. There I was, with PyTopo and a boring hotel room; I couldn't stop myself from tweaking a bit.

Adding tracklogs was gratifyingly easy. But other aspects of the code bother me, and when I started looking at what I might need to do to display those Tango/OSM tiles ... well, I've known for a while that some day I'd need to refactor PyTopo's code, and now was the time.

Surprisingly, I completed most of the refactoring on the trip. But even after the refactoring, displaying those OSM tiles turned out to be a lot harder than I'd hoped, because I couldn't find any reliable way of mapping a tile name to the coordinates of that tile. I haven't found any documentation on that anywhere, and Tango and several other programs all do it differently and get slightly different coordinates. That one problem was to occupy my spare time for weeks after I got home, and I still don't have it solved.

But meanwhile, the rest of the refactoring was done, nice features like track logs were working, and I've had to move on to other projects. I am going to finish the OSM tile MapCollection class, but why hold up a release with a lot of useful changes just for that?

So here's PyTopo 0.8, and the couple of known problems with the new features will have to wait for 0.9.

Tags: programming, python, gtk, pygtk, mapping
[ 19:49 Jun 20, 2009    More programming | permalink to this entry ]

The new gtk file selector fstab viewer

When I upgraded to Ubuntu Intrepid recently, I pulled in a newer GTK+, version 2.14.4. And when I went to open a file in GIMP, I got a surprise: my "bookmarks" were no longer visible without scrolling down.

In the place where the bookmarks used to be, instead was a list of ... what are those things? Oh, I see ... they're all the filesystems listed with "noauto" in my /etc/fstab --the filesystems that aren't mounted unless somebody asks for them, typically by plugging in some piece of hardware.

There are a lot of these. Of course there's one for the CDROM drive (I never use floppies so at some point I dropped that entry). I have another entry for Windows-formatted partitions that show up on USB, like when I plug in a digital camera or a thumb drive. I also have one of those front panel flash card readers with 4 slots, for reading SD cards, memory sticks, compact flash, smart media etc. Each of those shows up as a different device, so I treat them separately and mount SD cards as /sdcard, memory sticks as /stick and so on. In addition, there are entries corresponding to other operating systems installed on this multi-boot machine, and to several different partitions on my external USB backup drive. These are all listed in /etc/fstab with entries like this:

/dev/hdd   /cdrom  udf,iso9660  user,noauto               0  0
/dev/sde1  /pix    vfat         rw,user,fmask=133,noauto  0  0

The GTK developers, in their wisdom, have realized that what the file selector really needs to be. I mean, I was just thinking while opening a file in GIMP the other day,

"Browsing image files on filesystems that are actually mounted is so tedious. I wish I could do something else instead, like view my /etc/fstab file to see a list of unmounted filesystems for which I might decide to plug in an external device."

Clicking on one of the unmounted filesystems (even right-clicking!) gives an error:

Could not mount sdcard
mount: special device /dev/sdb1 does not exist

So I guess the intent is that I'll plug in my external drive or camera, then use the gtk file selector from a program like GIMP as the means to mount it. Um ... don't most people already have some way of mounting new filesystems, whether it's an automatic mount from HAL or typing mount in a terminal?

(And before you ask, yes, for the time being I have dbus and hal and fam and gamin and all that crap running.)

The best part

But I haven't even told you the best part yet. Here it is:

If you mount a filesystem manually, e.g. mount /dev/sdb1 /mnt ... it doesn't show up in the list!

So this enormous list of filesystems that's keeping me from seeing my file selector bookmarks ... doesn't even include filesystems that are really there!

Tags: gtk, user interface, humor, linux
[ 11:59 Mar 14, 2009    More linux | permalink to this entry ]

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 ]

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 ]

PyTopo 0.5

Belated release announcement: 0.5b2 of my little map viewer PyTopo has been working well, so I released 0.5 last week with only a few minor changes from the beta. I'm sure I'll immediately find six major bugs -- but hey, that's what point releases are for. I only did betas this time because of the changed configuration file format.

I also made a start on a documentation page for the .pytopo file (though it doesn't really have much that wasn't already written in comments inside the script).

Tags: programming, python, gtk, pygtk, mapping
[ 21:10 Aug 25, 2006    More programming | permalink to this entry ]

Cleaner, More Flexible Python Map Viewing

A few months ago, someone contacted me who was trying to use my PyTopo map display script for a different set of map data, the Topo! National Parks series. We exchanged some email about the format the maps used.

I'd been wanting to make PyTopo more general anyway, and already had some hacky code in my local version to let it use a local geologic map that I'd chopped into segments. So, faced with an Actual User (always a good incentive!), I took the opportunity to clean up the code, use some of Python's support for classes, and introduce several classes of map data.

I called it 0.5 beta 1 since it wasn't well tested. But in the last few days, I had occasion to do some map exploring, cleaned up a few remaining bugs, and implemented a feature which I hadn't gotten around to implementing in the new framework (saving maps to a file).

I think it's ready to use now. I'm going to do some more testing: after visiting the USGS Open House today and watching Jim Lienkaemper's narrated Virtual Tour of the Hayward Fault, I'm all fired up about trying again to find more online geologic map data. But meanwhile, PyTopo is feature complete and has the known bugs fixed. The latest version is on the PyTopo page.

Tags: programming, python, gtk, pygtk, mapping
[ 17:25 Jun 03, 2006    More programming | permalink to this entry ]

A Fast Volume Control App

I updated my Debian sid system yesterday, and discovered today that gnome-volume-control has changed their UI yet again. Now the window comes up with two tabs, Playback and Capture; the default tab, Playback, has only one slider in it, PCM, and all the important sliders, like Volume, are under Capture. (I'm told this is some interaction with how ALSA sees my sound chip.)

That's just silly. I've never liked the app anyway -- it takes forever to come up, so I end up missing too much of any clip that starts out quiet. All I need is a simple, fast window with a single slider controlling master volume. But nothing like that seems to exist, except panel applets that are tied to the panels of particular window managers.

So I wrote one, in PyGTK. vol is a simple script which shows a slider, and calls aumix under the hood to get and set the volume. It's horizontal by default; vol -h gives a vertical slider.

Aside: it's somewhat amazing that Python has no direct way to read an integer out of a string containing more than just that integer: for example, to read 70 out of "70,". I had to write a function to handle that. It's such a terrific no-nonsense language most of the time, yet so bad at a few things. (And when I asked about a general solution in the python channel at [large IRC network], I got a bunch of replies like "use int(str[0:2])" and "use int(str[0:-1])". Shock and bafflement ensued when I pointed out that 5, 100, and -27 are all integers too and wouldn't be handled by those approaches.)

Tags: programming, python, gtk, pygtk
[ 14:54 Jun 21, 2005    More programming | permalink to this entry ]

Python Expose vs. Focus

A few days ago, I mentioned my woes regarding Python sending spurious expose events every time the drawing area gains or loses focus.

Since then, I've spoken with several gtk people, and investigated several workarounds, which I'm writing up here for the benefit of anyone else trying to solve this problem.

First, "it's a feature". What's happening is that the default focus in and out handlers for the drawing area (or perhaps its parent class) assume that any widget which gains keyboard focus needs to redraw its entire window (presumably because it's locate-highlighting and therefore changing color everywhere?) to indicate the focus change. Rather than let the widget decide that on its own, the focus handler forces the issue via this expose event. This may be a bad decision, and it doesn't agree with the gtk or pygtk documentation for what an expose event means, but it's been that way for long enough that I'm told it's unlikely to be changed now (people may be depending on the current behavior).

Especially if there are workarounds -- and there are.

I wrote that this happened only in pygtk and not C gtk, but I was wrong. The spurious expose events are only passed if the CAN_FOCUS flag is set. My C gtk test snippet did not need CAN_FOCUS, because the program from which it was taken, pho, already implements the simplest workaround: put the key-press handler on the window, rather than the drawing area. Window apparently does not have the focus/expose misbehavior.

I worry about this approach, though, because if there are any other UI elements in the window which need to respond to key events, they will never get the chance. I'd rather keep the events on the drawing area.

And that becomes possible by overriding the drawing area's default focus in/out handlers. Simply write a no-op handler which returns TRUE, and set it as the handler for both focus-in and focus-out. This is the solution I've taken (and I may change pho to do the same thing, though it's unlikely ever to be a problem in pho).

In C, there's a third workaround: query the default focus handlers, and disconnect() them. That is a little more efficient (you aren't calling your nop routines all the time) but it doesn't seem to be possible from pygtk: pygtk offers disconnect(), but there's no way to locate the default handlers in order to disconnect them.

But there's a fourth workaround which might work even in pygtk: derive a class from drawing area, and set the focus in and out handlers to null. I haven't actually tried this yet, but it may be the best approach for an app big enough that it needs its own UI classes.

One other thing: it was suggested that I should try using AccelGroups for my key bindings, instead of a key-press handler, and then I could even make the bindings user-configurable. Sounded great! AccelGroups turn out to be very easy to use, and a nice feature. But they also turn out to have undocumented limitations on what can and can't be an accelerator. In particular, the arrow keys can't be accelerators; which makes AccelGroup accelerators less than useful for a widget or app that needs to handle user-initiated scrolling or movement. Too bad!

Tags: programming, python, gtk, pygtk
[ 20:52 Apr 09, 2005    More programming | permalink to this entry ]

PyTopo is usable; pygtk is inefficient

While on vacation, I couldn't resist tweaking pytopo so that I could use it to explore some of the areas we were visiting.

It seems fairly usable now. You can scroll around, zoom in and out to change between the two different map series, and get the coordinates of a particular location by clicking. I celebrated by making a page for it, with a silly tux-peering-over-map icon.

One annoyance: it repaints every time it gets a focus in or out, which means, for people like me who use mouse focus, that it repaints twice for each time the mouse moves over the window. This isn't visible, but it would drag the CPU down a bit on a slow machine (which matters since mapping programs are particularly useful on laptops and handhelds).

It turns out this is a pygtk problem: any pygtk drawing area window gets spurious Expose events every time the focus changes (whether or not you've asked to track focus events), and it reports that the whole window needs to be repainted, and doesn't seem to be distinguishable in any way from a real Expose event. The regular gtk libraries (called from C) don't do this, nor do Xlib C programs; only pygtk.

I filed bug 172842 on pygtk; perhaps someone will come up with a workaround, though the couple of pygtk developers I found on #pygtk couldn't think of one (and said I shouldn't worry about it since most people don't use pointer focus ... sigh).

Tags: programming, python, gtk, pygtk, mapping
[ 16:26 Apr 06, 2005    More programming | permalink to this entry ]

Python GTK Topographic Map Program

I couldn't stop myself -- I wrote up a little topo map viewer in PyGTK, so I can move around with arrow keys or by clicking near the edges. It makes it a lot easier to navigate the map directory if I don't know the exact starting coordinates.

It's called PyTopo, and it's in the same place as my earlier two topo scripts.

I think CoordsToFilename has some bugs; the data CD also has some holes, and some directories don't seem to exist in the expected place. I haven't figured that out yet.

Tags: programming, python, gtk, pygtk, mapping
[ 17:53 Mar 27, 2005    More programming | permalink to this entry ]

Topographic Maps for Linux

I've long wished for something like those topographic map packages I keep seeing in stores. The USGS (US Geological Survey) sells digitized versions of their maps, but there's a hefty setup fee for setting up an order, so it's only reasonable when buying large collections all at once.

There are various Linux mapping applications which do things like download squillions of small map sections from online mapping sites, but they're all highly GPS oriented and I haven't had much luck getting them to work without one. I don't (yet?) have a GPS; but even if I had one, I usually want to make maps for places I've been or might go, not for where I am right now. (I don't generally carry a laptop along on hikes!)

The Topo! map/software packages sold in camping/hiking stores (sometimes under the aegis of National Geographic are very reasonably priced. But of course, the software is written for Windows (and maybe also Mac), not much help to Linux users, and the box gives no indication of the format of the data. Googling is no help; it seems no Linux user has ever tried buying one of these packages to see what's inside. The employees at my local outdoor equipment store (Mel Cotton's) were very nice without knowing the answer, and offered the sensible suggestion of calling the phone number on the box, which turns out to be a small local company, "Wildflower Productions", located in San Francisco.

Calling Wildflower, alas, results in an all too familiar runaround: a touchtone menu tree where no path results in the possibility of contact with a human. Sometimes I wonder why companies bother to list a phone number at all, when they obviously have no intention of letting anyone call in.

Concluding that the only way to find out was to buy one, I did so. A worthwhile experiment, as it turned out! The maps inside are simple GIF files, digitized from the USGS 7.5-minute series and, wonder of wonders, also from the discontinued but still useful 15-minute series. Each directory contains GIF files covering the area of one 7.5 minute map, in small .75-minute square pieces, including pieces of the 15-minute map covering the same area.

A few minutes of hacking with python and Image Magick resulted in a script to stitch together all images in one directory to make one full USGS 7.5 minute map; after a few hours of hacking, I can stitch a map of arbitrary size given start and end longitude and latitude. My initial scripts, such as they are.

Of course, I don't yet have nicities like a key, or an interactive scrolling window, or interpretation of the USGS digital elevation data. I expect I have more work to do. But for now, just being able to generate and print maps for a specific area is a huge boon, especially with all the mapping we're doing in Field Geology class. GIMP's "measure" tool will come in handy for measuring distances and angles!

Tags: programming, python, gtk, pygtk
[ 11:13 Mar 27, 2005    More programming | permalink to this entry ]