mimeapps.list and mimetype inheritance

[David Faure]

On Monday 21 January 2013 13:15:11 Alexander Larsson wrote:
> On mån, 2013-01-21 at 12:06 +0100, David Faure wrote:
> > 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.
> 
> Well. I think there is a difference here, but merely one of degree. I
> can *imagine* a situation where you actually want to unzip an
> OpenDocument file. Its a very contrived situation, surely, but it will
> have happened at least some time in history, somewhere (like if you're
> an openoffice developer). 

Yes, but my suggestion is that if you want to open an OpenDocument file in a 
zip program, you can
1) run a zip program first and use File / Open.
2) add the zip program to the associated apps for OpenDocument files.

Having the zip program in the default associated apps sounds wrong.

> Possibly less contrived is the lilypond
> situation, as for example you have hit this :). Yet, I'd say that the
> vast majority of people using lilypond will not want to open is files in
> a text editor, whereas almost *all* people want to open c-src files in a
> text editor. 

Right, hence the idea of using "private inheritance" between lilypond and 
text/plain (it's technically feasible to read them in text editors, but text 
editors shouldn't show up by default in the associated apps for lilypond files, 
in file managers).

> That said is nice if the desktop *know* for instance that
> lilypond file is a text files, even if it didn't show them in the
> commonly seen UI (like open with). For instance, it could show it as a
> recommended app in the "open with other" dialog (and forever more in
> open with if you use this once).
> 
> So, I think there are essentially two kinds of derivations. Those that
> specialize the base class ("its a text file and normally used as such,
> but specifically its a Makefile"), and those that are mainly an
> "implementation detail" ("its a document for some specific app, but for
> internal reasons it is a xml file"). And I think we should handle these
> differently in the UI.

Yes. We seem to agree.

Hence my followup question which was: how do we implement this in the spec :)

> > > (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?
> [...]
>
> No no no. What i mean is that if a desktop files claims:
> "MimeType=x/base-class;x/subset-of-base-class" then we ignore the
> x/subset-of-base-class part as its already handled by x/base-class.
> Whereas if the desktop file *only* lists x/subset-of-base-class then we
> keep it.
> 
> That way we'd parse the emacs desktop file in your example as only
> specifying text/plain. Emacs would still *open* text/x-csrc files due to
> inheritance of course, its just easier to override it.

Oh! This makes a lot of sense, and fixes the problem quite easily.
Yes, of course, let's do that.

Should we mention this in a spec? The desktop entry spec doesn't really tell 
much about what happens with the MimeTypes key, and the mime-actions-spec is 
about mimeapps.list, not about desktop files. The issue here is the interaction 
between the two :-)

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