update to new mimeapps.list specification

[David Faure]

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:
[Default Applications]
foo/bar=foo1.desktop
[Added Associations]
foo/bar=foo2.desktop;foo3.desktop;foo4.desktop
- or -
[Default Applications]
foo/bar=foo1.desktop,foo2.desktop;foo3.desktop;foo4.desktop
- or  -
[Added Associations]
foo/bar=foo1.desktop,foo2.desktop;foo3.desktop;foo4.desktop
(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