mime aliases and inheritance vs. removed associations
adys.wh at gmail.com
Sun Nov 9 12:25:20 PST 2014
Agreed on aliases.
As far as inheritance goes... Let's look at it on a case by case basis.
The user opens an HTML file. It opens with Firefox. They set notepad as the
app for HTML -> Notepad can now read HTML files.
Notepad should not implicitly be suddenly interested in all text files.
Let's imagine a "b64ark" format which stores multiple files in a base64
plain text format. This format inherits from text/plain but the user
associates it with Ark or some such, it doesn't mean ark can read all
plaintext files. This would happen a lot with XML files as well for example.
OK now let's imagine Firefox can read XML and svg files. The user doesn't
want it to open XML files so removes the assoc. It doesn't mean chrome
should stop reading svg files.
With all that in mind I don't think we should care too much about
inheritance unless it is explicit.
On Nov 9, 2014 8:18 PM, "Ryan Lortie" <desrt at desrt.ca> wrote:
> One more nag about the mimeapps spec, while we're at it.
> We didn't take any care to think about aliases and inheritance.
> Aliases are probably relatively easy: I think we should aim to only ever
> store the canonical mime type names in the file, and if we are
> processing a file with non-canonical names, we should treat it as if we
> encountered the canonical name instead. That means that if someone
> added an association at one level for 'application/acrobat' and then at
> another level removed 'application/pdf' then the result would be that
> the association is broken, regardless of what string is used to do the
> Inheritance is more difficult. What does it mean if, for example, gedit
> is listed as an editor for text/plain, but then we specifically list it
> as a [Removed] for text/html? Maybe even more interesting is what
> happens if it explicitly listed as text/html but then we remove it for
> all of text/plain? Is it only removed as a fallback, or is it removed
> completely for all purposes?
> I don't know that there are "natural" answers to these questions. In
> the case of GLib we have two loops iterating (outer) over all parent
> types, in order of most specific to most general, then (inner) over all
> desktop file directories. If we encounter a remove instruction anywhere
> on the way, we add the app to a blacklist that we keep for the duration
> of the entire operation. This means that if an app removed for
> text/html at any level it will prevent it from being used for text/html
> even if it is added again for text/plain from a higher-level directory.
> This might sound weird, but consider that removals are probably only
> really recorded at the highest-level (ie: user) directory.
> On the other hand it means that if the user removes text/plain then the
> behaviour will depend on what exactly was specified in the system
> directories. If text/html was specifically mentioned as being handled
> then it will still be handled. If, however, only text/plain was
> mentioned, then the user will have removed this association. That seems
> slightly weird as well.
> I guess it comes down to user intent in a way: what is the user really
> wanting to do when they break an association between an generic text
> editor and a file named index.html? Are they breaking an association
> between this editor and all text files, or are they only intending to do
> it for html? Maybe the solution to this problem in fact lies in
> breaking specifically the association that the application declared?
> I welcome any thoughts on this matter (and particularly if you can state
> them more cogently than I've been able to do in this mail).
> xdg mailing list
> xdg at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg