update to new mimeapps.list specification

[Ryan Lortie]

hi,

I've been communicating with David about updates to make some minor
tweaks and clarifications to the new mimeapps.list specification that he
drafted. Here is what I have.

The main gist of the changes:

Added and Default are now completely separate with their separate
reasons for existing greatly clarified.

For added/removed, we now consider desktop files and mimeapps.list to be
handled at the same time. Previously, all instructions, from even the
lowest level mimeapps.list (ie: /usr), had precedence over desktop
files, even if they were installed at the highest level (user's
homedir). This is no longer the case. We consider .desktop files
listing MimeType= in a directory alongside a mimeapps.list file as being
equivalent to those desktop ids appearing under [Added Associations]
(after any entries that are already there).

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.

Default is now a very simple process: we simply go through all of the
mimeapps.list files, in order, looking for defaults. The default app is
the first one we find a desktop file for. We do not care if the desktop
file is available from a higher-precedence directory.

Put simply: installing a desktop file in a higher precedent directory
will cause lower-level added/removed associations impacting that
application to be ignored, but not declarations of defaults. This makes
sense because we don't expect that associations will be added or removed
at the lower levels, but we do expect that the distro may provide a
reasonable set of defaults.

When handling added/removed, there is simplicity gained by treating
desktop files as more or less the same as mimeapps.list. In fact, the
existing mimeinfo.cache file looks quite a lot like mimeapps.list
(except for a different group name) and we can very easily use it
directly as if it were just another mimeapps.list file. It also allows
us to make only one pass through the directories while collecting the
list of applications that support a given type, which will be
particularly useful once we have the cache (since we only need to store
supported type information in the file in one place).

Cheers

[Ryan Lortie]

Post by Ryan Lortie
Here is what I have.

uh... the patch, of course (attached).

[Vladimir Kudrya]

Please clarify this:
"add to the blacklist the names of any desktop files found in the same
directory as the mimeapps.list file"
How "temporary" the blackist is in this algorithm?

If we are dealing with actions (add/remove), then why not to reduce
complexity of the algoritm and just compose *one* list of associations
from global to local by taking described actions?
1. go to the most global dir
2. Add from .desktop's
3. Add according to mimeapps.list
4. Remove according to mimeapps.list
5. move to next more local dir
6. goto 2

Strict linear logic, one list, no temporary lists, no 'if's, even no
"implementation-defined behaviour", local always overrides, KISS.

[David Faure]

Post by Vladimir Kudrya
"add to the blacklist the names of any desktop files found in the same
directory as the mimeapps.list file"

You find foo.desktop (associated with the given mimetype), you add foo.desktop
to the result list, but then you add foo.desktop to the blacklist too, so that
you don't add foo.desktop again.

Post by Vladimir Kudrya
How "temporary" the blackist is in this algorithm?

Temporary until the end of the algorithm :-)

Post by Vladimir Kudrya
If we are dealing with actions (add/remove), then why not to reduce
complexity of the algoritm and just compose *one* list of associations
from global to local by taking described actions?
1. go to the most global dir
2. Add from .desktop's
3. Add according to mimeapps.list
4. Remove according to mimeapps.list
5. move to next more local dir
6. goto 2

Yes, that should be equivalent, and is the whole point of how added/removed
works. However, if you only need the first N apps to show in a list, then
better start from the other side (most-local first).

And if you only need to find the default application, then better start from
the most-local dir too (since you can stop as soon as you find one that is
installed).

So overall, it's simpler to only have algorithms that start from most-local,
than to have both kinds depending on the use case.

But of course you are free to implement it starting from most-global and going
up. An algorithm in a spec is just a suggestion, and helps understanding, it's
not the only way to implement it.

[Vladimir Kudrya]

Post by David Faure

Post by Vladimir Kudrya
"add to the blacklist the names of any desktop files found in the same
directory as the mimeapps.list file"

You find foo.desktop (associated with the given mimetype), you add foo.desktop
to the result list, but then you add foo.desktop to the blacklist too, so that
you don't add foo.desktop again.

Post by Vladimir Kudrya
How "temporary" the blackist is in this algorithm?

Temporary until the end of the algorithm :-)

Post by Vladimir Kudrya
If we are dealing with actions (add/remove), then why not to reduce
complexity of the algoritm and just compose *one* list of associations
from global to local by taking described actions?
1. go to the most global dir
2. Add from .desktop's
3. Add according to mimeapps.list
4. Remove according to mimeapps.list
5. move to next more local dir
6. goto 2

Yes, that should be equivalent, and is the whole point of how added/removed
works. However, if you only need the first N apps to show in a list, then
better start from the other side (most-local first).
And if you only need to find the default application, then better start from
the most-local dir too (since you can stop as soon as you find one that is
installed).
So overall, it's simpler to only have algorithms that start from most-local,
than to have both kinds depending on the use case.
But of course you are free to implement it starting from most-global and going
up. An algorithm in a spec is just a suggestion, and helps understanding, it's
not the only way to implement it.

OK, now I finally have the full picture. And I find the spec misleading,
the way it is written now. I suggest you first describe the essence of
the algorithm global>local way, since it is in fact the "natural",
"uncompressed" logic of the algorithm. And then give an example of how
it can be reordered to achieve optimal performance.
Well, human-digestible form first, machine-digestible form after that ;)

[David Faure]

Post by Vladimir Kudrya
OK, now I finally have the full picture. And I find the spec misleading,
the way it is written now. I suggest you first describe the essence of
the algorithm global>local way, since it is in fact the "natural",
"uncompressed" logic of the algorithm. And then give an example of how
it can be reordered to achieve optimal performance.
Well, human-digestible form first, machine-digestible form after that ;)

I agree.

[David Faure]

Post by Ryan Lortie

Post by Ryan Lortie
Here is what I have.

uh... the patch, of course (attached).

I have pushed your patch now, finally :)

[Ryan Lortie]

hi,

Post by David Faure
I have pushed your patch now, finally :)

Thanks for this, and great timing. I just fixed a bug that was
preventing GLib from actually correctly implementing the very same spec.
:)

Cheers

[David Faure]

Post by Ryan Lortie
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).

[Ryan Lortie]

hi David,

Post by David Faure
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).

Can you make the change to the patch that you would like to see?

Alternatively, I could push what is already there and you could
introduce the changes as a separate commit.

fwiw, in implementing it, I think your local-first approach ends up
being easier and more efficient (mostly due to not having to add items
and remove them later, possibly only to re-add them).

Cheers

[David Faure]

Post by Ryan Lortie

Post by David Faure
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).

Can you make the change to the patch that you would like to see?
Alternatively, I could push what is already there and you could
introduce the changes as a separate commit.

Yes, please push what you have, I can extend the documentation afterwards.
That seems easier.

Post by Ryan Lortie
fwiw, in implementing it, I think your local-first approach ends up
being easier and more efficient (mostly due to not having to add items
and remove them later, possibly only to re-add them).

OK.