Yeah, that's a helpful response, UPS customer service.
Thursday, June 27, 2019
Monday, June 3, 2019
Onwards
The completely innocent cat
I can see my house from here
Cat sleeping on top of the world
Tom prowling
Fast moving Tom
Why I had to rearrange my games collection
Monday, May 13, 2019
The inevitable followup
You all knew this was coming, right?
Gardens are fun
Trees are hard
The perfect spot
So many things to climb
Inevitable, I guess.
A not unexpected complication
Friday, April 19, 2019
Is this thing on?
Oh, hey, long time no use of this blog.
I break my silence because, as is universally acknowledged, there are not enough pictures of cats on the internet, and certainly not enough pictures of this cat.
This is Tom, who is gradually taking possesion of my house, and over the next while I will be trying to rectify the lack of photographs on the internet.
This is Tom, who is gradually taking possesion of my house, and over the next while I will be trying to rectify the lack of photographs on the internet.
Monday, September 25, 2017
Photos, redux again, repeated.
I've left the university of Stellenbosch, which unfortunately means I can no longer rely on dip.sun.ac.za for hosting my photos.
Thus I've moved everything to a VM instance, running at photos.drnlm.org
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.
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
Whizzard
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.
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.
Subscribe to:
Posts (Atom)