update to new mimeapps.list specification
faure at kde.org
Tue Apr 15 13:17:45 PDT 2014
On Sunday 13 April 2014 17:53:45 Ryan Lortie wrote:
> The fact that order is important for "most preferred" is clarified. The
> fact that the default may be different than the most preferred is also
> clarified. In GNOME, we use most preferred to mean most-recently-used,
> which could very well be different than the desired default.
When explaining the spec to someone else, I realized that this bit was the
hardest to explain & understand.
"Most preferred" really does sound like what "Default" is about, i.e. picking
the app that the user prefers to open when clicking on the file.
But I'm not sure how to name it otherwise than "preferred", to explain the
fact that :
1) the user-local [Added] list is ordered according to "some preference order"
2) the user-local [Default] app is usually just one app, as chosen by the
user, while global files list multiple Defaults in order to fallback if some
apps are not installed
3) the user-local [Added] lists act as fallback if no [Default] is there, so
the concepts are indeed somewhat tied.
Assuming all these .desktop files already list the mimetype foo/bar,
one *could* write the same thing in many different ways:
- or -
- or -
(and no Default Applications for foo/bar anywhere)
With all these, the end result is the same: foo1 is started by default,
and an ordered list would show foo1,foo2,foo3,foo4.
Maybe to clarify the whole purpose of this, we can point out that the spec is
this way so that GUIs can write out a single [Default] in the user's
mimeapps.list, and can keep an ordered list in [Added]. It's not mandatory to
do so, but it's the main reason for ordering to matter in the [Added] list.
GUIs that want to just show an ordered list with most-preferred-equals-default
at the top (rather than a list of radiobuttons like Gnome does), can just
write out the ordered list to [Default] (and any missing associations to
[Added], but then order there doesn't matter). So for people with such GUIs in
mind, it's harder to understand the spec, the fact that ordering matters in
both Default and Added seems redundant from that point of view :)
Other than that, the patch to the spec looks good to me, thanks.
Maybe we can list both algorithms (local-to-global and global-to-local) in the
first section, for clarity (cf the discussion on the list).
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
More information about the xdg