small nag about mime apps spec

[Ryan Lortie]

hi,

I have a small nag about the mime apps spec that has been bothering me
for a while:

The interaction between [Default Applications] and [Removed
Applications] at a higher level is strange.

In particular, what happens if we have
/usr/share/applications/mimeapps.list advertising that gedit.desktop is
the default for text/plain but then the user has recorded a [Removed
Applications] in their ~/.config/mimeapps.list.

The text in the spec is this:

"""
Note as well that the default application for a given type can be an
application that is not associated with this type (ie: neither by
MimeType= or an added association, or even in the case that the
association was specifically removed). Such configurations should be
regarded as unusual, however, and implementations should not write
mimeapps.list files that create this circumstance.
"""

We considered that it would be "unusual" to get into this situation but
I don't think we fully thought-out specifically how to avoid this
situation. In order to avoid it, we'd have to ensure that when removing
the formerly default app for a given file type, we'd need to add a new
default app to the user's mimeapps config. How do we chose such an app?
Random? Second place after the removed app? What if there is no 2nd
app?

In retrospect, I'd like to modify the specification to require that an
app is valid for a given type in order to be considered as a default.
This would mean that removing an association would also cause an app to
stop being considered as the default and would let us avoid this strange
wording about "regarded as unusual".

As a caveat, it would add a slight complication to the code for deciding
the default app.

Thoughts?

[Jerome Leclanche]

Post by Ryan Lortie
In retrospect, I'd like to modify the specification to require that an
app is valid for a given type in order to be considered as a default.

+1. If someone wants to make an app default, they would have to add
the association then. Sounds completely reasonable and if it
simplifies the spec, great.

J. Leclanche

[David Faure]

Post by Ryan Lortie
We considered that it would be "unusual" to get into this situation but
I don't think we fully thought-out specifically how to avoid this
situation. In order to avoid it, we'd have to ensure that when removing
the formerly default app for a given file type, we'd need to add a new
default app to the user's mimeapps config. How do we chose such an app?
Random? Second place after the removed app? What if there is no 2nd
app?

Well, either you have to resolve this question at the time of marking the
application as removed (moment 1), or you have to resolve this question at the
time of launching a file of that type (moment 2). In essence it's the same
question that has to be resolved anyway.

Your suggestion below moves the decision from the former to the latter, that's
all. I'm not opposed to it, but I also don't see a huge benefit in doing so.

Well, more precisely: you're suggesting this is resolved at moment 1, which
still leaves the question of what to do when launching an app and it wasn't
already resolved (i.e. the GUI for marking an application as removed didn't
take care of choosing a new default app), so we also have to implement
something to resolve the question at moment 2 anyway, no?
(or indeed specify it as "unusual" again, since it's not supposed to happen?)

Post by Ryan Lortie
In retrospect, I'd like to modify the specification to require that an
app is valid for a given type in order to be considered as a default.
This would mean that removing an association would also cause an app to
stop being considered as the default and would let us avoid this strange
wording about "regarded as unusual".

[Ryan Lortie]

hi,

Post by David Faure
Well, either you have to resolve this question at the time of marking the
application as removed (moment 1), or you have to resolve this question at the
time of launching a file of that type (moment 2). In essence it's the same
question that has to be resolved anyway.
Your suggestion below moves the decision from the former to the latter, that's
all. I'm not opposed to it, but I also don't see a huge benefit in doing so.

This is true and I never considered it from this angle.

Looking at it from another angle, though, consider what we have to do in
order to make the two cases equivalent. As you said, we would have to
make a decision at 'moment 1' (ie: when a file association is removed).
This means, in effect:

1) check if the app being removed for the assocation was the default
2) find a new default
3) hardcode this new default into the user's config "at moment 1".

So that means that an operation to remove a file association for a
default app would also result in an additional new "default" line being
written out for an unrelated application. That's possible, but it seems
weird to me.


There is one other case, though, that is not exactly equivalent, no
matter what we do. In the case that the removed association is the
_only_ default app available, then what? I suppose we select one other
non-default app at random to record as the new default. But what if
there are no other apps for this mimetype at all? I would expect the
behaviour in this case to be that we get a "open with?" dialog or
similar, but under the current regime there would be absolutely no way
to prevent the removed association from remaining as the default app.

Additionally: consider the case that the app that we chose (perhaps more
or less at random) as our new default is uninstalled. In that case, we
fall back to the old default, which would be our removed application.


Cheers

[Ryan Lortie]

hi,

Post by Ryan Lortie
There is one other case, though, that is not exactly equivalent, no
matter what we do. In the case that the removed association is the
_only_ default app available, then what? I suppose we select one other
non-default app at random to record as the new default. But what if
there are no other apps for this mimetype at all? I would expect the
behaviour in this case to be that we get a "open with?" dialog or
similar, but under the current regime there would be absolutely no way
to prevent the removed association from remaining as the default app.
Additionally: consider the case that the app that we chose (perhaps more
or less at random) as our new default is uninstalled. In that case, we
fall back to the old default, which would be our removed application.

I think I managed to convince myself enough to write a patch.

Let's move discussion to bugzilla?

https://bugs.freedesktop.org/show_bug.cgi?id=86069

Cheers