I’m trying out iStockphoto

One of three images:

For the 3rd time in a row, one of my designs has been chosen as one of 2 options for the official Ubuntu countdown banner

Besides the official options, there are PHP versions that allow to have changing images even in places where no JavaScript is permitted. Such as this blog! Use one of the snippets below, thanks to Huber Florian:

Andrew Higginson’s design:

<a href="http://www.ubuntu.com"><img src="http://neogates.ath.cx/~huwa/ubuntuKarmic/karmic2.php" id="countdownimage" alt="Ubuntu 9.10 Countdown"></a>

Mine:

<a href="http://www.ubuntu.com"><img src="http://neogates.ath.cx/~huwa/ubuntuKarmic/karmic1.php" id="countdownimage" alt="Ubuntu 9.10 Countdown"></a>

The problem with hierarchical file systems

It’s clear that hierarchical file systems are not good for organizing music or photos. In short, the problem is having several attributes of interest, where no single one of them is more suited to lend structure than others. This same problem applies to all kinds of documents too, but the needs and wants regarding meta-data are more variable and harder to tackle there.

Specialized library-management applications, one for each kind of media, lead to a fractured user experience and data islands. It should be possible to exchange objects with meta-data over the net, without the user having to take special care. There needs to be a generalized solution.

This topic is old enough to be discussed in the FLOSS realm

As long as hierarchical filesystems stay around as layer on the bottom, there will be cases where users are exposed to them. For example on installation, backup and restore. Generally all cases concerning the physical location of data. You get a leaky abstraction. The fewer concepts the user has to deal with, the better.

I think object storage with attributes should happen on the file system level, so applications can build on a common foundation and there is no lower layer poking through.

Storage location as attribute

With current files systems, storage location is implied by the path of a file. On systems of the unix family, with single-rooted file system trees, it’s not even obvious which drive a given path maps to. One symptom of this is that dragging files in a file manager from one place to another will either move or copy the files, depending on whether the places are on one drive or not. Quite a bit of background information is required until a user can understand this behavior.

I think storage location should be dealt with explicitly. To do so, it could be presented to the user as just another attribute in the form of a list of one or more locations.

• Storage locations could be partitions on various media, or servers that do not reveal actual physical location.
• Locally there would need to be a catalog of all known objects along with their lists of storage locations. It would have to be updated on remote changes.
• Each location would have a catalog for its own content. However, I’m not sure if these should contain complete lists of the other locations per object.
• To identify objects across several locations, they would need to have unique IDs as sole invariable attribute.

Combined with versioning, this could be an elegant way to deal with:

• Downloads: store the origin of the initial version with date of retrieval
• Uploads to file hosts or directly to contacts. It’s just adding a location for a specific version.
• Constant mirroring of important data to another local location without any special tools.
• Tracking backups. Keeping note of what versions of objects are stored on what removable media.
• Mirroring/synchronization. Remote locations could be coupled with a schedule for synchronization.

During my ongoing work on an SVG based theme to be realized with the gtk-css-engine I became aware of a number of shortcomings in GTK+.

There’s no Prelight on menus and tabs, making them feel like dead space. There’s an old bug report with patch for this, but it started out as being specifically for the Windows port:
http://bugzilla.gnome.org/show_bug.cgi?id=340203

No Active (depressed) state for entries. This is admittedly controversial:
http://bugzilla.gnome.org/show_bug.cgi?id=589971

Full size

Treating the parts of a SpinButton like separate widgets works against drawing arrows “inside” a SpinButton. Also the focus indication isn’t drawn around the whole widget like it should be, for this reason:
http://bugzilla.gnome.org/show_bug.cgi?id=589973

There shouldn’t be focus indication on only the current tab of a Notebook:
http://bugzilla.gnome.org/show_bug.cgi?id=589975

Full size

There should be support for drawing the sides of tabs differently depending on whether they line up with the page or not:
http://bugzilla.gnome.org/show_bug.cgi?id=589981

Full size

Pastel chalk and coloured pencils on 2 layers of paper (DIN A 3). No digital editing besides color correction and fixing the highlights in the eyes, as they didn’t appear like on the original. Drawn as birthday present for my dad. He really likes oranges and poppy

Full size 1675 x 2842 pixels

So after several more variations and tweaks, alternative proposals and feedback from several people, it looks like we finally have a definitive logo for Lumiera:

Original Concept by anamii

A public Git repo and Firefox’s ability to display at least basic SVG have been a great help.

Christian Thäter made a nice variant for the Credits page.

Following some feedback on the ubuntuusers.de forum (German), I softened the shapes, added outlines and shading:

This is the current ubuntuusers.de logo:

Thinking about what it might be meant to represent somehow led me to:

Mainly for my German readers: All the fuss about banning Paintball and Laserdome, cutting off Internet access on repeated copyright infringement and most of all the stop-sign bullshit from van der Leyen inspired me to this:

Available on shirts at spreadshirt.net.

Sharp cutoffs on the dark edge of the frame, asymmetrical bows on u and m, ra tweaked to match the m, quick hack to try bolder type with rounded corners:

The SVG source of this image.