small nag about mime apps spec

Ryan Lortie desrt at
Sun Nov 9 08:41:34 PST 2014


On Fri, Nov 7, 2014, at 02:51, David Faure wrote:
> 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.


More information about the xdg mailing list