Ryan Lortie
2014-11-09 19:18:04 UTC
hi,
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
lookup.
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).
Cheers
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
lookup.
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).
Cheers