mimeapps.list and mimetype inheritance

[David Faure]

On Monday 21 January 2013 10:57:04 Alexander Larsson wrote:
> 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".

I am surprised by this reply. Isn't this what mimetype inheritance is all 
about? What's the point of mimetype inheritance, if not to say that "an app 
which declares being able to handle text/plain, can handle anything that 
derives from text/plain"?

We talked (when we saw each other for a few minutes in Gran Canaria) about 
adding a "private inheritance" mechanism for the cases where the inheritance 
is an implementation detail that shouldn't surface to the user when just 
clicking on the file (but it could be useful when explicitely using "File / 
Open" in the application). Your example back then was OpenDocument files, which 
inherit application/zip, but which should never open in a ZIP application by 
default, from the file manager. However, if a ZIP application wants to verify 
that the file chosen in its File / Open dialog is indeed a zip file, then it 
wants to include private inheritance.
If you're still interested, let's discuss how to add private inheritance to 
the spec. In the XML it's easy, but I wonder about the caches etc.
 
> 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. 

Yes, of course.
It's just that I have no control over emacs.desktop :-)

> 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 

I can't parse this sentence, it talks about opening applications in a text 
editor !?

> (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?

You're suggesting to ignore inheritance altogether? How then would we be able 
to open the myriad of text/plain subclasses (those that are really close to 
text/plain, the READMEs, Makefiles, scripts, .spec files, etc. etc.)? We would 
have to list all the mimetype explicitely in all text editors? This doesn't 
sound very appealing. I thought this was exactly what inheritance was all 
about: if you can handle text/plain, you automatically handle all of these.

Otherwise, every time we add a subclass, we break opening these files with 
existing apps. This is not the idea of inheritance, it should be seamless...

The use case for private inheritance exists (OpenDocument), but shouldn't be 
the default, it's more much rare.
(Even lilypond isn't a good use case for it -- I did edit lilypond files by 
hand in the past).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5