shared-mime-info/xdgmime news

We didn’t have any shared-mime-info release for some time, with the last one dating back to March 2005. Much work has been accomplished recently, though. Debian patches were pushed upstream, and – which is really nice – we finally found a solution for the long-standing issue of multiple MIME types per extension, causing media container b0rkage. This rectifies a new release within the next few weeks.

Let me go a bit into detail on the “multiple MIME types per extension” issue:
Some of you might already have noticed that when Nautilus determines the contents of a file to be different from the extension, and you select it, it is suddently changing its icon, getting resorted when you sort by MIME type etc. This inter alia used to be a widespread phenomenom for windows media files, and constantly happened for all of them.

In terms of MIME handling, media “containers” are quiet evil.

You often have multiple media streams encapsulated into one file/stream (this is called “multiplexing”). The enclosing stream/file is called container. When naively looking at the container’s file extension, it is not possible to tell what the contents is. Since nowadays there are many media container formats available, like Ogg or ASF, it is cruicial to deal properly with those encapsulated streams, and give the user the possibility to associate audio players with encapsulated audio, and video players with encapsulated video.

To make the situation worse, mistakes were made when determining MIME types for containers. For instance, all Ogg files are meant to have the MIME type “application/ogg”, according to the IANA. This is a very bad idea, for the bad user experience pointed out in the last paragraph.

Summing up the above, the MIME container analysis revealed two major attach points:

a) never ever determine the MIME type of a container without peeking its contents
b) we need more MIME types

a) was resolved to 98% by Matthias Clasen who improved the xdgmime API to include support for this. Because the container concept can’t simply be mapped to mime type definitions, he took a different approach: He hacked support for N:M relations between filename glob patterns (“*.ogg”) and MIME types into xdgmime, adding API for querying whether multiple MIME types for a particular glob pattern exist. Thus, xdgmime can now can query whether multiple MIME types exist for a particular passed-in file name, and find out whether peeking its contents is always required, telling its client that the actual MIME type is unknown. The last 2% were slight adaptions of helpers exported in the API to actually make GnomeVFS semantics work correctly with it, which was my contribution.

Note that these changes can also be extremely important useful for other use-cases, like the file extension “*.pot” being assigned to translation templates and powerpoint presentations.

b) for Ogg, the task was quiet straightforward:
“application/ogg” is used for “*.ogg” and its magic matchlet (the sniffing information) matches against all Ogg files.
The trick is now to define new MIME types for the encapsulated streams, all of which also match “*.ogg”, the Ogg magic matchlet mentioned above, and an additional stream type-specific magic matchlet:
“audio/x-vorbis” maps to “Ogg Vorbis audio”
“audio/x-oggflac” maps to “Ogg FLAC audio”
“audio/x-speex” maps to “Ogg Speex audio”
“video/x-theora” maps to “Ogg Theora video”

additionally, we have a “OGM video” MIME type matching “*.ogm”, which contents-wise matches a modified version of the Ogg magic matchlet. It is a bit legacy, considering that this was mainly added because the crappy Windows MIME system doesn’t allow any contents sniffing, and is used to identify Ogg videos.

All of the mentioned stream types are registered as sub-types of “application/ogg”, so that old MIME associations are not broken and apps operating on the container itself still work as expected.

a) and b) were resolved today for Ogg, b) hasn’t been resolved for ASF yet, but I’m quiet optimistic that it will make it into the next shared-mime-info release as well.

This is really a major progress in xdgmime/shared-mime-info, and should convince the KDE guys to take a close look at the bundle for KDE 4, although I can’t tell how editor-friendly the shared-mime-info file structure is. I doubt they’ll tell users that MIME associations are the distributors job and they should just file bugs if something goes wrong, like we did. MIME type editing will probably still be possible in KDE 4. If the MIME editor friendlyness of the structure is bad, take it as a revenge for the over-complex arcane XML-based menu system we adopted ;).
Congrats to KDE 3.5, btw.


Peter Bowen points out that a MIME naming following the XML naming spec (“video/x-foo+ogg”) would be more convinient. I agree and changed it accordingly.

C# and GNOME

Looks like the next few weeks will be cruicial to the future of GNOME. We’re arriving at a point where it’s obvious that we have to talk about what role C# should play in a future desktop. I don’t want to blog much yet, since it’s really too early to draw any conclusions. A thread on the foundation list dealing with questions to the board election candidates yielded a discussion that may become interesting. It was initiated by Richard M. Stallman, whose main two theses are:

For GNOME to include C# support as an optional add-on cannot hurt. (…) I think it is clear that C# should not be the main or preferred
language for GNOME, should not play a major or central role. Giving it such a role would be a very bad strategic move, since it would
encourage a large community to move in a direction that serves our declared enemy.

as well as

The hard question is whether to give C# a middle-level role–whether to let it be more than an optional add-on. The issue depends on the legal situation (…).

I’ve tried to elaborate a bit on his first thesis and prove that if deploying C# in FOSS projects doesn’t really help Microsoft in any way. We should really be thankful that Microsoft invented a useful platform like .NET. C# seems to attract many developers and yield many interesting applications that wouldn’t have been developed otherwise:

(T)he most convinicing product wins, not that one promoted by politic(i)ans.

IANAL, but concerning the legal situation, I also made clear that don’t think that nowadays there are any other problems with C#/.NET adoption than those that would have arised with any other bulky/extensive technology when it comes to patents. Patent infridgement almost definitly already happened (as laid out in my email), and definitly will happen in future, no matter what technology we use.

Let’s ignore that unavoidable situation, for now. Lawyers and judges tend to be very incalculable when it comes to lawsuits dealing with ideological questions that have a direct impact on law, instead of with formal arguments. The good news is that with FOSS there is always a way out, as long as there exist countries that don’t have software patents comparable to those in the USA.

Meanwhile, the nautilus-search branch of Nautilus which aims towards Beagle integration is progressing nicely. Will we experience the normative power of the factual. Will the new board deal with this question?

Stay tuned, and join the foundation-list discussion!

Mozilla/GTK+ patch review request

The GTK+ wrapper around Mozilla always overrides the global X11 cursor. It shouldn’t do so if it uses the normal cursor (GDK_LEFT_PTR), though. Maybe a Mozilla/GTK+ developer could give my patch a spin? I know, it looks like a tiny issue, but it is totally weird that when you spwan a startup notification-capable application while browsing, you don’t get any cursor feedback.

Spreading Ubuntu

We’ve been very successful at spreading Ubuntu CDs among students over here at the Technische Universität in Munich. Today, I’ve distributed 250 of them among the students of Electrical Engineering, and Moritz Angermann was even able to distribute around 1000 among the students of Computer Science, Mathematics and Physics.
All of them originated from Murray’s cellar. There are still loads of them available, so if you need a bunch of them, just ask him :).

Re: Suboptimality

Ross: I like your signal emission proposal! Sadly, GnomeVFSDrive doesn’t have any padding.

On the application startup itself: If we use the MIME type approach, it may be neccessary to add a hidden desktop file for each application (like gthumb-camera-handler.desktop), since the “Exec” line might not be appropriate.

I’ve also noted that “ghumb –import” doesn’t take any additional arguments. Shouldn’t it receive the BUS/Device/ID triple of the camera? Maybe we need new positional parameters for these very special use cases.


Murray points out that one does not have to specify default signal handlers in the class vtable upon signal registration, which obviously renders my concerns pointless. This proves how well-thought out and flexible our core GObject system is. Kudos to Matthias Clasen and all the other hackers :).

On an unrelated sitenote: g_signal_override_class_closure seems to provide a mechanism to override the default handler for subclasses, although this isn’t relevant for GnomeVFSDrives. The g_signal_add_emission_hook API also looks very interesting.

GNOME Volume Manager Sub-Optimal! (was: Re: Sound Juicer Sub-optimal?)

Jeffrey Stedfast writes:

Ross Burton writes:
> > So. Someone puts in a CD. A while later, although there’s no
> > indication something is happening, sound-juicer pops up.
> This is a bug in gnome-volume-manager: it doesn’t give you any feedback
> that it is probing the new media, or starting Sound Juicer. I think a notification
> area icon for “new media inserted” would be good whilst it probes, and then
> the standard startup notification animation/panel entry when it starts up
> Sound Juicer.

This is actually completely false. No probing of audio CDs is ever done by g-v-m – any probing done on the device is done by the kernel/HAL/somewhere-lower-in-the-stack and so not only is the fault not with g-v-m for this delay, but g-v-m also cannot possibly report any notifications/progress/whatever.

I think Ross does not refer to the fact that probing a device takes time, but exclusively to the fact that gnome-volume-manager does not use startup notification. It simply executes /desktop/gnome/volume_manager/autoplay_cda_command.

IMHO, we should rather use a special key in .desktop files specifying that a particular application handles a particular media type (i.e. VolumeManagerBlankCDExec=foo %s, VolumeManagerDVDExec=bar %s, etc.). If we add gnome_desktop_item_launch_full to the GNOMEDesktopItem API, allowing the client application to specify another key than “Exec”, we’ll be able to pick up all applications with such a key and let GNOME Desktop ensure that the “StartupNotify” key is evaluated.

This would also resolve the following usability rant. I’ve felt exactly the same when seeing the dialog for the first time, btw.:

I realize that providing a drop-down list of known applications would only throw a very small light on what the system usually offers. However, the average desktop user neither knows about commandline parameters nor even about the names of all the applications he uses because the GNOME naming schema (in menus and so forth) differs from the real application names (they’re not localized, for example).

I think somebody already came up with a similar proposal, at least I remember seeing a mockup.

nautilus-open-terminal 0.5 (0.6), now with SFTP/SSH support

Grab nautilus-open-terminal 0.5 while it’s still hot. Thanks to the excellent work of Guillaume Desmottes you can now launch SSH sessions in terminals out of Nautilus SFTP sessions at the cwd.

Translation contributors to this release: Ilkka Tuohela (Finnish), Yuval Tanai (Hebrew), Young-Ho Cha (Korean), Žygimantas Beručka (Lithuanian), Pawan Chitrakar (Nepalese), Michał Kastelik (Polish), Baris Cicek (Turkish), Maxim Dziumanenko (Ukrainian) and Clytie Siddall (Vietnamese).


I forgot to mention that this release is dedicated to Hans-Eckardt Wenzel, who released the excellent Woody Guthrie tribute album Ticky Tock (English review).

Update 2

Released nautilus-open-terminal 0.6, which ensures that the Polish translation is actually compiled/installed and also includes the Norwegian translation by Kjartan Maraas., GNOME rant

I’ve been trying to get my old CVS account renewed for more than 2 months now. I filed a bug report and kindly and repeatedly asked on IRC. I was told that they have no admin ressources or got no response at all. I’m curious how many of your efforts were already massively slowed down by the lack of clear rules and responsibilities. I’m also perceiving similar problems in GNOME, where lack of time by people in charge who mostly work on distro-specific stuff that has nothing to do with stock GNOME, or lack of clear accountings already proved to scotch many efforts.

Back to Nobody seems to care for my bugs and some bugs in the GNOME bugzilla depend on them, like this one (cf. related GNOME bugzilla rant by Erich Schubert). Whoever can arrange that my CVS account works again, he’ll be my very special hero of this weekend and get a free beer.


Eric Anholt deserves beer!

On a sidenote: I always think it’s kind of sad if people get what they want exclusively because of some sort of advantage over others (i.e. some people are not able to rant in blogs), or rather the position they have in a community. Bugzillas are IMHO really meant to work in a socialistic fashion by being polite and treating all bug reports equal.

Helping newbies is fun

Helping people on gtk-app-devel-list is fun, especially when familiarizing them with C pitfalls. I’ve written a little lineup describing four common C pointer argument conventions:

1 void foo (const void *bar);

means that bar will definitly not be modified. While the foo author
could theoretically force to free or modify it, that would require casting the const away and whoever does it is on crack:
C uses call by value. So after invoking foo, which could do free ((void*)bar), and set its local copy of bar to NULL, the outer bar variable is undefined. Using it further will most likely result in a crash, including calling free (bar); in the outer frame again.

2 void foo (void **bar);

This is some sort of call by reference. You pass the address of the bar
variable, i.e. char *foobar = …; foo ((void **) &foobar); This syntax
ensures that the foo function can dereference its local copy of &foobar,
and make *bar (which is foobar) point to NULL after freeing, or
reallocate it – do all the pointer magic (except for pointer arithmetic,
because it is a void * pointer in this case).

3 void * foo (void *bar);

This will also work on the local copy of bar, and
– if it changes bar – return that changed value, i.e. the new address of its local bar copy. So you can invoke it
like char *foobar = …; foobar = foo (foobar);.

I’ve never seen any function acting like that, to be honest.

4 void * foo (const void *bar);

Just some flavor of 3, which will always return newly allocated memory
in addition to that already allocated for bar, while not modifying the
eel_str_strip_chr uses this variant.


Tollef points out that flavor 3 is used for realloc.