Many years ago, when koffice was fresh and with few users, I
decided to test its presentation tool when making the slides for a
talk I was giving for NUUG on Japhar, a free Java virtual machine. I
wrote the first draft of the slides, saved the result and went to bed
the day before I would give the talk. The next day I took a plane to
the location where the meeting should take place, and on the plane I
started up koffice again to polish the talk a bit, only to discover
that kpresenter refused to load its own data file. I cursed a bit and
started making the slides again from memory, to have something to
present when I arrived. I tested that the saved files could be
loaded, and the day seemed to be rescued. I continued to polish the
slides until I suddenly discovered that the saved file could no longer
be loaded into kpresenter. In the end I had to rewrite the slides
three times, condensing the content until the talk became shorter and
shorter. After the talk I was able to pinpoint the problem –
kpresenter wrote inline images in a way itself could not understand.
Eventually that bug was fixed and kpresenter ended up being a great
program to make slides. The point I'm trying to make is that we
expect a program to be able to load its own data files, and it is
embarrassing to its developers if it can't.
Did you ever experience a program failing to load its own data
files from the desktop file browser? It is not a uncommon problem. A
while back I discovered that the screencast recorder
gtk-recordmydesktop would save an Ogg Theora video file the KDE file
browser would refuse to open. No video player claimed to understand
such file. I tracked down the cause being file --mime-type
returning the application/ogg MIME type, which no video player I had
installed listed as a MIME type they would understand. I asked for
file to change its
behavour and use the MIME type video/ogg instead. I also asked
several video players to add video/ogg to their desktop files, to give
the file browser an idea what to do about Ogg Theora files. After a
while, the desktop file browsers in Debian started to handle the
output from gtk-recordmydesktop properly.
But history repeats itself. A few days ago I tested the music
system Rosegarden again, and I discovered that the KDE and xfce file
browsers did not know what to do with the Rosegarden project files
(*.rg). I've reported the
rosegarden problem to BTS and a fix is commited to git and will be
included in the next upload. To increase the chance of me remembering
how to fix the problem next time some program fail to load its files
from the file browser, here are some notes on how to fix it.
The file browsers in Debian in general operates on MIME types.
There are two sources for the MIME type of a given file. The output from
file --mime-type mentioned above, and the content of the
shared MIME type registry (under /usr/share/mime/). The file MIME
type is mapped to programs supporting the MIME type, and this
information is collected from
the
desktop files available in /usr/share/applications/. If there is
one desktop file claiming support for the MIME type of the file, it is
activated when asking to open a given file. If there are more, one
can normally select which one to use by right-clicking on the file and
selecting the wanted one using 'Open with' or similar. In general
this work well. But it depend on each program picking a good MIME
type (preferably
a
MIME type registered with IANA), file and/or the shared MIME
registry recognizing the file and the desktop file to list the MIME
type in its list of supported MIME types.
The /usr/share/mime/packages/rosegarden.xml entry for
the
Shared MIME database look like this:
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="audio/x-rosegarden">
<sub-class-of type="application/x-gzip"/>
<comment>Rosegarden project file</comment>
<glob pattern="*.rg"/>
</mime-type>
</mime-info>
This states that audio/x-rosegarden is a kind of application/x-gzip
(it is a gzipped XML file). Note, it is much better to use an
official MIME type registered with IANA than it is to make up ones own
unofficial ones like the x-rosegarden type used by rosegarden.
The desktop file of the rosegarden program failed to list
audio/x-rosegarden in its list of supported MIME types, causing the
file browsers to have no idea what to do with *.rg files:
% grep Mime /usr/share/applications/rosegarden.desktop
MimeType=audio/x-rosegarden-composition;audio/x-rosegarden-device;audio/x-rosegarden-project;audio/x-rosegarden-template;audio/midi;
X-KDE-NativeMimeType=audio/x-rosegarden-composition
%
The fix was to add "audio/x-rosegarden;" at the end of the
MimeType= line.
If you run into a file which fail to open the correct program when
selected from the file browser, please check out the output from
file --mime-type for the file, ensure the file ending and
MIME type is registered somewhere under /usr/share/mime/ and check
that some desktop file under /usr/share/applications/ is claiming
support for this MIME type. If not, please report a bug to have it
fixed. :)
