Recent discussion on the Gnome-shell list made me think about file handling in general once again.

I think it would be beneficial to Gnome (or KDE or …) to have a long term plan regarding where some fundamental things should be heading. Here’s some food for thought, knowing that everything I bring up here comes with a long tail of questions:

Uniform file handling liberated from hierarchical file systems

Every new/separate piece of interface the user has to deal with means more to learn and more to remember (several instead of one mental model). This speaks against a separation between accessing files and managing files (a design decision for Nautilus that I wasn’t aware of, previously). It also speaks against having various interfaces for documents, images, audio and video files, each designed independent of the other.

The problems of having to deal with huge numbers of items and no sane way to put each item into only one category (folder) affects not only media files, but also documents.

Meta-data (tags, categories, relations) is the answer regarding organizing and accessing files. This should be handled in a uniform way for all kinds of files (maybe with exceptions for some system files).

But there’s a problem as long as users have to deal with hierarchical file systems. Meta-data on top means there will be situations users have to understand and deal with 2 systems where on could suffice. The question where files are actually stored should be part of the meta-data in some way.

Versioning

More people should get to enjoy the benefits of versioning. You shouldn’t have to drop to the CLI or install GUI tools. Versioning should be just there as open invitation and comfortable helper.
(Heck, a whole system installation could be a clone from a distribution repo, I guess.)

EDIT: KDE’s Dolphin will have version control support, although not quite in the open, direct way I’m envisioning.

Sharing

We not only deal with more files of an increased number of types, but also have more means of transfer and more places they end up on. Time for tracking which file in which version went where or to whom right from your desktop. The same mechanism could also help with managing archives on removable media.

To link or embed?

Should images in a presentation be linked or embedded? Both have their pros and cons. How about neither? As long as all parts are on the local system, use references to files. References that do not rely on a path or filename and thus do not break. If the main document is copied to a different system, make sure all the required files follow.

I have been asked for a logo for aubio, so let’s start with a few ideas:

Sampo Savolainen asked me to design an audio compressor plugin GUI. This triggered a thought process with a first result that is guaranteed to be far way from what he had in mind, but before I may head in a more conventional direction, I just have to explore this

Background info on dynamic range compression.

I wondered how one could express what each control of a compressor as the one written by Sampo does. Giving an idea of the signal path and relations between controls. Ideally without labels, even.

Full size

The controls provided are:

• High-pass filter on/off for the analyzed signal. Left side. Here I neglected that the signal is split in 2, one for measurement, the other to apply the effect on.
• Treshold. Green line in the graph. Should be draggable from the whole grap area.
• Ratio. Blue fader with round knob, synchronized with the blue line/dot in the graph.
• Markup gain. Fader with red arrow. The graphics show the relation to the first graph.
• Attack and Release time. Below the stop watch icon. I’m worried that the chart below the faders is rather hard to get, so it might be best to drop it and to add labels.
• Dry/wet amount. Right side. The output touching the right corner and the fader handle for this are one.

High-pass switched off:

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: