Monday, September 25, 2017

Photos, redux again, repeated.

I've left the university of Stellenbosch, which unfortunately means I can no longer rely on for hosting my photos.

Thus I've moved everything to a VM instance, running at

And, because I can, Photos from my recent trip to Hermanus with Simon and Armin.

Thursday, January 28, 2016

Playing with Python 3 & Gtk (or What I did with my Summer Vacation)

Oh, yeah, I still have this blog thing.

As is fairly obvious to people who've seen my homepage, I take quite a lot of photographs. While I'm a big fan of using file system hierachies to categorise information, and it's fundamental to the way my Gallery software  works, there are nuances that are hard to represent with a single hierachy.

For years, I've used f-spot to maintain a tagged database of my photos, which makes various queries a lot simplere. Of course, f-spot has always been annoyingly buggy, and is now essentially dead and increasingly suffering from bit-rot. The official replacement, shotwell, is nice enough, unless you're the sort of person you cares about how the data is actually stored in the database, in which case it's not for you. (I shall not eloborate - the curious can easily shotwell's behaviour themselves). Since I'm the sort of that does care, shotwell's out. There is digikam, but Ive never hit it off with the KDE design philosophy, so that doesn't work well for me either.

Which of course leaves the traditional solution to minor inconviences with other people's software. Re-inventing the wheel. This does have a number of advantages. I can have something that just has the features I want, and drop a lot of stuff, such as all the image editing functionality, that there are better tools for. Furthermore, by writing in python 3, using gobject introspection and a pre-release of SQLObject, I can justify it both as a learning exercise (since I hadn't previously gotten beyond toy gtk3 programs), and also as testing SQLObject 3.

The net result of all this is Phototagger , something I'd actually decided to write in 2014 (but then as a python 2 program), but then didn't do any work on for more than a year, and which now represents far too much of my free time over the last month and a half or so.

There was a point early on where the actual code design was reasonably neat, but stuff got tangled as I worked around some questionable early choices without addressing the underlying problem, so a rewrite is on the cards at some point, but it now works pretty nicely.

The features are nothing special - photos can be added, tagged, tags can be edited and have various images assigned to them, and all that sort of thing. The search functionality is a bit limited - it doesn't allow constructing arbitary tag queries, but it covers the sort of queries I generally need.

Indivual photos can be viewed

And zoomed - this also supports mouse panning, which took a surprisingly long time to get right due to a misreading of the Gtk documentation.

As a learning experience, it was pretty useful. I got to play with some of the new Gtk 3 widgets, such as the Stack and FlowBox widgets, which are nifty, and work through some of the changes between Gtk 2 and Gtk 3. It's also given me a fair amount of confidence in SQLObject's python 3 support, although it doesn't stress the limits of SQLObject particularly.

As a tagging tool, it's now functional enough to replace f-spot for me, and has proved a great deal more stable. I now just need to rewrite a bunch of the tools I wrote to managing my f-spot database easier, and then I can finally move on.

Tuesday, July 22, 2014


As I've mentioned a few times, I spend a reasonable amount of my free time (and sometimes bits of my not free time ("compiling!")) working on Sutekh, our card manager for VtES.

As I've also mentioned, I created a fork of Sutekh called Thufir, which does the same thing for the defunct Dune CCG. While I got Thufir to a point I was happy with, I never really kep it up to date with Sutekh's developments, so the two code bases diverged rather rapidly.

Now we add the recent Android: Netrunner LCG into the mix. While there are a varierty of web-based card managers for A:NR, I find them clunky, and there's a dearth of other options. Maintaining a third fork of Sutekh also looked really unappealing, so I hatched a cunning plan to refactor Sutekh considerably, pulling a lot of non-VtES specific code into a nice, reasonably reusable basis for writing card management applications. I also reworked Thufir to use this new framework, fixing a lot of bugs and gaining a whole lot of new, useful features there. Of course, this all took time, and, as a result, I didn't get around to actually working on my A:NR app (called Whizzard).

Over the weekend, I decided to knuckle down and actually start working on this. Although there is still missing data and a bunch of features to hook up, it's moved past the vapourware stage really quickly, which gives me a warm fuzzy feeling about the refactoring work done on Sutekh.

Sutekh's base infrastructure is still not quite as self-contained as I'd like, which would avoid needing to duplicate code in the various repos, but I still haven't come up which a way of plugging the last couple of leaks I'm happy with, so I'll live with the current state of affairs until inspiration strikes.

Wednesday, February 5, 2014


Sometime towards the end of last year, I lost an argument about how traffic lights work with a minibus taxi. While I got off reasonably unscathed, my poor Honda didn't, which was a very sad experience.

Consequently, I spent some time looking for a suitable replacement. This took longer than I wanted, due to general end of year craziness, but eventually resulted in something I quite like.

Now that I have the licensing all sorted out, I hope to be able to enjoy the remaining good biking weather before winter sets in suitable style.

Sunday, April 21, 2013

Pyweek 16: Nemesis

So we've reached the end of another pyweek, and I've managed another game ("Bane's Befuddlement"), so it's time for my usual post-pyweek post.

Since most of the usual suspects were busy with other things, I ended up doing a solo entry for the first time. I also decided, on something of a poorly thought-out whim, to use kivy for this entry.

Based on what happened with Mad Science (pyweek 14), I expected the solo entry to be something of struggle, and it does show in the end result. Artwork was obviously limited, since it's not my strong suite and I didn't want to spend a lot of time on the issue, but fortunately I was able to offset that somewhat by using one of the existing dungeon tile collections.

Probably the most crucial failing is ambition. Several of the past pyweek entries I'm been involved in have suffered from being overly ambitious (Nine Tales (pyweek 12) being the worst offender), so I aimed to avoid that pitfall this time. As a result,  I was under-ambitious. The game isn't that challenging, and is a bit bland. It's not without potential, but needed more time spent on the initial concept to really get something I would have been happy with.

There are several things I am happy with. I reaffirmed my belief in the importance of level editors for pyweek games. Even with the very simplistic one I wrote here, I was able to fill out the level content very quickly on Friday and Saturday as a result, and I rather like the careful level of stupid that AI achieves.

There are a few tricks about touch interfaces I need to learn. The most obvious one from this game is to avoid anything that goes too close to the edge of the screen - it's too easy to accidentally trigger one of the other buttons in that case.

As an exercise in working more with kivy, this was pretty successful. I'm still uncertain about how I feel about kivy. It's quite nice in some ways - being able to add a settings pane or a popup dialog with only a couple of lines of code - but it's also all sorts of magic in ways that really aren't helpful. The complicated import dance needed to ensure that we set the configured window size before creating the kivy window is just one example of this sort of thing. More annoyingly, the inability to hook in to the command-line argument parsing without some serious monkey patching is the sort of poorly thought out design that makes working with it painful.

Python's still a work in progress on android, and, while it's possible to use pyjnius to access the hardware, and to build apk's, both require more fiddling with building python for android than I was prepared to do during a pyweek, so, while the game runs OK on my phone, it's missing some features which would be very nice to have. There is enough work happening in this space that this should improve, though.

Windows packaging with kivy is a pain, and the recommended approach of using pyinstaller just failed horribly for me. I'm not sure if where to lay the blame for that, but debugging windows issues is not my favourite activity, and anyway not something I'm capable of doing at the end of a pyweek.

Thursday, November 22, 2012

Thoughts on the 2012 VTES Leagues

I had intended to blog about the league more, but that fell by the wayside, and got replaced by the game reports. I'll intend to do better for the next league.

Having now run two leagues, I think I can safely say it was a good idea. It's given a bit more structure to the local VTES games, and ensured that we keep having regular socials, which is needed to keep the game alive. It's also allowed me to fiddle with several deck ideas in fairly serious competition without the risks of a tournament.

Keeping the league running is fortunately fairly low-effort, and I've gotten a lot of the score management and tracking reasonably automated (working on which has been a useful "compiling" project). I'm not sure we've quite got the length of the league right yet - people seem to get a bit burnt out both times, so we should maybe shorten it a bit more, but I'd like to avoid long breaks in the game, simply to help keep interest up.

I'm not sure if it's accomplished my other goal of improving my play level. I have had a couple of games where I feel I've played really well, and made some good decisions in some somewhat non-obvious positions, but I've also made a number of really stupid errors, and thrown away a couple of potential game wins as a result.

On the other hand, I did manage to top both leagues, which suggests I'm doing something right. However, I partly topped the league by simply playing a lot more league games than everyone else. I feel somewhat guilty about that, as I feel I've been gaining an unfair benefit from the way the league rules were setup to not penalize people playing lots of games, and, as the main driver of the league, I'm partly responsible for the rules we chose.

Sunday, May 13, 2012

Pyweek 14: Mad Science

So we've reached the end of another pyweek, and managed yet another game ("Tomorrow, the World!!!"), so it's time for my usual post-pyweek post.

It's not one of the better entires I've been involved in, and I expect us to place very middle of the field this year. I think there's a decent concept here, but we didn't get enough content or game balance to have something that's really fun, and, as a result, much of the early game is a bit random and frustrating. There's nothing unfixable, but it needs a couple of days of people playing and extending the game to get to the point I'd actually be happy with it. It's got its entertaining bits, though, so I'm happy enough to throw it out there to be judged and see what happens.

Due to everyone being busy and / or being out of the country, we had a much smaller team than previous entries. I expected we would need to downscale as a result, but this proved to be more of a problem than I had actually anticipated. There just wasn't space for people to play the game much, which partly accounts for the issues, and there also much less opportunity to riff off other people's ideas to improve things. Everyone being busy in the day didn't help either. There were far fewer of the "ooh, a bunch of cool stuff has happened since I last worked on the game" moments, which also made it feel like more of a slog than past entries. The lack of people was most felt in the final Saturday finishing sprint, for which only 2 of us were available - most conversations were "I'm fixing X, can you look at Y?", and then silence for about 30 minutes while stuff happened. Given how the smaller team affected things, my respect for people doing successful solo entries has gone up even further.

I've now been involved 5 pyweek entries, and they've all been content heavy in various ways, so it's fair to call that as a definite trend. Given the games I enjoy playing, and the high value I place on being amusing, that's not surprising, but it's not a good feature for games with small teams.

On the upside, it was still fun. Coding for pyweek is always liberating, since it's much more important to have something close now than completely correct later. Having now done 3 pyweeks with mercurial, we've now also got the setup and workflow around that reasonably well sorted (which means we're almost certainly due to change to something else now), and past experience means that we're making a reasonable number correct design decisions early, so I'm quite happy with the final structure of the game.