mimeapps.list and mimetype inheritance

[Alexander Larsson]

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). 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. 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.

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

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.

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

I mean any file with such a "text/plain subset" mimetype (i.e.
text/x-lilypond in the lilypond case). Like, in your example, if emacs
only listed text/plain it would be easy to override with kate, yet such
an override would not cause us to change the default for lilypond (which
does not mention text/plain in its desktop file).