mimeapps.list and mimetype inheritance

[Alexander Larsson]

On ons, 2012-12-26 at 19:31 +0000, David Faure wrote:
> Hi Alexander,
> 
> When you implemented support for mimeapps.list in glib, did that include 
> looking up inherited mimetypes, or is that not supported?
> 
> Here's an example.
> emacs.desktop says:
>    MimeType=text/plain;text/x-csrc;
> My mimeapps.list says:
>    text/plain=kde4-kate.desktop;emacs.desktop;
>   (and has no entry for text/x-csrc)
> 
> When opening a text/plain file, kate is selected, no problem.
> But when opening a text/x-csrc file, emacs is selected.
> Is this expected?
> 
> The question is: should the user's preference for text/plain have priority 
> over the fact that a .desktop file mentions the derived mimetype explicitely?
> As a user, I would expect that (so that I can select a text editor for all 
> inherited mimetypes in one click).
> But implementation-wise, this is a bit tricky, because of the interaction with 
> multiple dirs in XDG_DATA_DIRS, and with "Removed Associations", so I was 
> wondering if this was implemented in glib, and if so, whether we could agree 
> on a common algorithm.

Glib doesn't currently do anything like this (although it does handle
aliases used in the mimeapps.list file). 

I'm not sure using inheritance in this case is correct though. I mean,
it seems "right" in your example, but thats just because text/x-csrc is
really "very close" to text/plain. If you take another example of a
text/plain subclass such as application/mathematica,
application/postscript, text/calendar, or text/x-lilypond it doesn't
seem as obviously right. I mean its *possible* to open these with an
editor, but its really not something most people expect to do, so I'm
not sure it should be in the UI "by default".

So, maybe there is a different kind of solution possible. For instance,
in this case the problem is that emacs hardcodes some subsets of
text/plain, making it hard to override that. But except for this problem
there is no gain in having emacs specify that, is there? It will still
open e.g. text/x-csrc files.

So, in a setup where emacs only listed text/plain your example would
work right. Additionally, any desktop file that listed only a text/plain
subset and not text/plain, such as lilypond, would *not* show up as
openable in kate (unless the user specifically added it to
mimeapps.list). So, maybe we could just fix desktop files to not do
this, or even ignore such subclass mimetypes when parsing the MimeType
field. Would there be any problems with this?