Default Program | File Association

[David Faure]

Continuing a very old thread about the unwritten mime action spec....

Thomas Leonard <tal00r <at> ecs.soton.ac.uk> writes:
> 1. "*.html is text/html" is specified by a <mime:glob> element in the input,
>    and output to the 'globs' file by update-mime-database.
>
> 2. "text/html is an 'HTML page'" is specified by a <mime:comment> element
>    in the input, and output to text/html.xml by update-mime-database.
>
> 1 & 2 are already done that way.

OK so far (and implemented in KDE 4).

> 3. "text/html can be viewed with Firebird" is specified by a
>    <desktop:viewable-with> element in the input, and output to text/html.xml
>    by update-mime-database. This element is defined in a separate spec.

The problem is that "text/html can be viewed with Firefox"(*) is already
specified: firefox.desktop says "MimeType=text/html;" (and a bunch of other
mimetypes). So we don't need a new spec that redefines this. When you install
your distribution's firefox package, it installs a .desktop file that says what
it can handle, and that point is covered...... almost. The remaining question
is, how should the user be able to add an application to a given mimetype.

Here's how it worked in KDE3:
If I add the application gwenview to the mimetype image/svg+xml, then kde3 will
copy /usr/share/applications/kde/gwenview.desktop into
~/.local/share/applications/kde-gwenview.desktop and add the new mimetype to
the MimeType key.
In a sense this works well, because it only uses the existing specifications...
except the small detail that kde/gwenview.desktop is associated with the name
kde-gwenview.desktop internally so the local file hide the global one (on
purpose, we don't want both to show up in menus).

This "copying and hiding" also means that if you upgrade gwenview and it
handles more mimetypes, or has a fix in any other desktop entry, your kde won't
know it.
For this reason, I'm open to a solution with a single text or xml file in the
user's local dir, but then it has to be able to specify not only adding but
also removing mimetypes from the installed desktop files (e.g. if you want to
de-associate an app from a mimetype even though its global desktop file
mentions that mimetype).

(*) we're talking about a browser, not about a relational database ;-)


> 4. "text/html should by default be viewed with Mozilla" is handled by the
>    configuration system, not by the MIME database.
> 4 is entirely separate, and requires us to spec the configuration system
> first.

I don't really agree that it's "entirely separate". The default application has
to be one of the associated applications, otherwise it wouldn't make sense. So
we might as well store preferences as part of that too.

The way it works in KDE3 (just for reference, I don't mind changing this in
kde4 if we can decide fast on something better) is:
* .desktop files come with an InitialPreference key, highest means most
preferred. It's not exactly true that "each application author wants his app to
be the highest", in practice people have been quite reasonable, and there are
definitely cases where the app author knows he doesn't want to be the preferred
app for a given mimetype (e.g. okular can import ODF documents but its author
just agreed to set the InitialPreference to 2 instead of 7 since a reader-only
application should definitely not be preferred over a full-fledged office
suite).
* ah yeah, and there's support for per-mimetype preference, using ugly syntax
like MimeType=text/plain;5;image/svg+xml;2. Hmm. Maybe we ought to split this
out into a separate section of the .desktop files instead... I'm thinking of
[InitialPreferences]
text/plain=5
image/svg+xml=2
which doesn't replace the "MimeType=text/plain;image/svg+xml;" line of course,
it would only set the per-mimetype preference number.

Back to kde3:
* when the user changes the order of the associated applications, we save this
into a local "profilerc" config file (INI-style syntax). Current syntax is a
bit strange, I wrote something better for kde-internal components already,
where the syntax is more like
[image/svg+xml]
NumberOfEntries=2
Entry0_Service=gwenview.desktop
Entry0_Preference=4
Entry1_Service=kview.desktop
Entry1_Preference=0
0 means "disabled", which is a way of ensuring that kview is not used for this
mimetype even though kview.desktop specifies it.
OK that's still a bit strange syntax (was the easiest to write with KConfig),
I'm really fine with standardizing on some xml equivalent of it.
The point is that this file is only written out by the configuration module and
only read by the "what's associated with what" piece of code, it's not like
every application author will have to mess with it.

Now the interesting part is that saving the application order also means saving
which applications are associated with a mimetype, so this could be used to
solve point 3 as well....

What do you guys think? Could we keep "desktop files specify their mimetypes,
and optionally the initial preference to use for this application, for all
mimetypes or per mimetype", and simply add an XML file for the user
configuration?
In order to suggest something more precise I'll just write an example of the
above converted to XML:
<mimetype name="image/png">
   <service name="gwenview.desktop" preference="4"/>
   <service name="xli.desktop" preference="3"/>
   <service name="kview.desktop" deleted="true"/>
</mimetype>

Sorry for the long post,

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).