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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
