mimeapps.list and mimetype inheritance
faure at kde.org
Mon Jan 21 03:06:30 PST 2013
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
> (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
More information about the xdg