01:59: Release 0.1.1

I just posted my first bugfix-release.

More-compact LZMA-compressed archives, along with GPG signatures, are also available in the directory:

• http://www.rozzin.com/VisualIDs/

I've also decided to post the patches that enable VisualIDs in various versions of Nautilus (2.18 thru 2.24):

http://www.rozzin.com/VisualIDs/nautilus-patches/

If you're using a Debian-based system, using the Nautilus patches is even easier than usual:

• apt-get source nautilus
• Copy the 99VisualIDs.patch file for your version of Nautilus into the debian/patches/ subdirectory of the Nautilus package's source-tree.
• cd into the source-tree and build Nautilus, e.g.:
  • dpkg-buildpkg -rfakeroot -b -us -uc
• Install your new VisualIDs-capable Nautilus, e.g.:
  • sudo dpkg -i ../*nautilus*.deb

Note that my patches for Nautilus are still somewhat crude at this point--I haven't learnt to use GConf yet, so the way that you enable/disable VisualIDs at run-time is to create/remove the ~/.icons/VisualIDs/scalable directory (which is where the VisualID SVG-files will be cached).

[Reply]

20:25: VisualIDs Visualisation

I've started hacking on an editor-application for the VisualID glyphs:

All of the parameters of a VisualID glyph can be adjusted dynamically with real-time feedback. Ultimately, this should become something that end users could utilise to tune their VisualIDs experience to their liking; but something like this can also be extremely useful as an exploratory design-tool for me, to help visualise the implications of choices that that I make in code. I can play with with parameters and see, for example, how well the 2:1 line-to-border ratio actually works in a variety of situations. I can look for trends, and I can even instrument the system to help me spot the trends. Then I can improve the algorithms.

In the hands of an end user, the editor could obviously assist on a case-by-case basis (e.g.: `Oh--I don't like that, maybe if I tweak it like this...'), but repeated use of the editor could also actually teach the system to better match the user's aesthetics in future glyph-generation by logging the user's edits to a statistical database. Well, maybe.

As it stands right now, the editor... needs some work before I post the code (it's pretty rough, right now), but here are some preliminary screenshots--the following images show a single VisualID producer being reparameterised several different ways:

[Reply]

22:16: Initial Public Offering

I've posted `version 0.1' tarballs, along with a Bazaar repository; it's all available at:

• http://www.rozzin.com/VisualIDs/

I've got what I believe are working patches against a couple different versions of Nautilus, copies of which have been given to few people for preliminary feedback.

I guess I should work up the gumption to post the nautilus-patches publicly, soon.

[Reply]

20:58: Computing Similarity, and Computing Difference

Way back in June or July, I had dinner with Chris and Allli, and I got to do a little demo to show-off my VisualIDs-in-Nautilus work as far as it had progressed at that point. Since I'd just started thinking about the problem of identifying similar files in a global context, and was (somewhat stupidly) proud of myself for having come up with a way of seemingly making it easier than I'd initially expected it to be, I raised it in conversation; regrettably, this (along with the talk about my new job) resulted Chris and I marooning Allli in geekspeak....

When I initially read the essay, this part (like so many other parts) looked great (`on paper', as they say?). When I initially dug in as an implementor, this part (like so many other parts) looked more half-baked: deriving icons in a group from the same source made fine sense, but how were the groups to be formed?

But then I thought about it some more, and it occurred to me that, since I was keeping a cache of VisualIDs and the names to which they belonged, I could just scan through the cache whenever a new VisualID needed to be generated, see if I could find an appropriately-similar base-ID, and then go from there--this would be where the `longer than 3 characters' part of the matching-algorithm came in. All I would need to do in order to guarantee that this actually worked was to ensure that all of the VisualIDs were generated synchronously, which actually turned out to be easy enough in Nautilus--I ended up hooking into the thumbnail-generation subsystem, which was already synchronous anyway.

Chris posited the obvious flaw in this scheme: if one has multiple computers, wouldn't one want the icons to be consistent across all of them? If the consistency breaks down, then doesn't the utility break down?

But, unless we have some way of coordinating between the distinct systems, this looks like a hard problem: we can't just use the `ouija-board navigation' technique, we actually have to come up with some sort of consistent algorithm for gleaning some sort of meaningful structure of free-form file-names. Chris didn't think it'd really be that hard of a problem. I'm not convinced that it's anything like easy.

It looks like I can actually punt, though--I can say:

If you want multiple computers to synchronise their repertoires of VisualIDs, then just synchronise their cache-directories--how you do it is outside the scope of this project; you should be able to use whatever mechanism you use to synchronise other files between computers.

And, for the time being, that's what I'm doing: I just added my .icons/ directory to my Unison configuration, and now it gets synchronised between my laptop and my desktop along with the rest of my home-directory. It works--it actually works really well. And it would work using any of the other zillion synchronisation-systems available; for GNOME, it might make sense to do it via Conduit--it probably works just using whatever generic file-synchronisation mechanism Conduit provides, but it looks like a specific `Synchronise Icons' option would be easy enough to add.

So, every aspect of grouping similar icons together is really pretty easy, at least as far as I can see.

Where it looks like things get difficult is actually in reverse: guaranteeing that different and unrelated things actually look different, and that things don't end up with similar icons just-by-happenstance. How can that be managed? Can we just assume that the PRNG will make it work out that way?

If anyone has any specific thoughts on either issue, I'd love to hear them....

[Reply]

23:25: Porting from Nautilus 2.20 to 2.22

So far, I've been working with Nautilus 2.20, because that's what Debian is shipping in Lenny. Mainline Nautilus is actually up to 2.22, and there have been significant changes to the APIs between 2.20 and 2.22. In particular, nautilus-icon-factory.c, which is where the bulk of my patch applies..., has been /removed/. Luckily, it's easy to find where the code went--and most of it is still even substantially similar, just in a different file. So, the port to 2.22 should be fairly easy.

My patch for Nautilus actually didn't end up being that big, anyway--it basically just changed the default behaviour of the thumbnailer-subsystem.

[Reply]