hi, On Tue, Apr 8, 2014, at 3:55, David Faure wrote: > Adding and removing mimetypes (at all levels) is "patching the complete > view of .desktop files for the current user".
I have come to think of this as a mistaken idea. There are just too many steps in the process if we handle it this way. Let's say we have the desktop cache available at each level which has desktop files (which is the ideal case for considering the performance characteristics). When constructing the desktop cache, I want to be able to make a simple list of which mime associations are added and removed by this directory. I specifically don't want to have to keep a separate list of "mime types added via desktop files here" vs. "mime types added via mimeapps.list". This allows a very simple algorithm: I go through the directories once and collect the added types (applying the blacklist at each step). I don't then have to make a second pass through all the directories checking the mime information from the desktop files. This is particularly problematic when considering 'removed' associations added at an intermediate level. For example, this (perhaps slightly ridiculous case): /usr/share/applications/foo.desktop: MimeTypes=text/plain /usr/local/share/applications/mimeapps.list: Removes foo.desktop from text/plain ~/.local/share/applications/foo.desktop MimeTypes=text/plain In order to know that the mime type in foo.desktop in ~/ are to be ignored, I first have to go down through the list a first time to collect the mimeapps.list information and then come back up for a second go through the desktop file information. Recall that both of these sets of information are in the same cache file. If I want to do it in one go, I must keep track of which additions to the applications for a supported mime type came from mimeapps.list and which came from (universally lower-priority) desktop files. The caveat of this is that at each level, I have to take care not to do anything for mimeapps entries that refer to desktop files present at a higher level. This is not a substantial problem with the way my code is already structured. Even assume that these extra checks are expensive. So maybe that means in terms of performance, the situation is actually a wash -- but I still think that the expectation would be that a mimeapps.list in /usr/share/applications acts as a modification to the MimeTypes= lines in the files that we find there. This implies that a new desktop file at the homedir level would ignore these modifications. Certainly, I might be confused if I install an app that lists support for a particular mime type, but it's not supporting it due to something listed in a lower-level directory. Note: this discussion is _only_ about added/removed. We might sidestep the whole issue by saying that only the ~/.config and /etc versions of the files can add and remove associations (since this feature is of questionable usefulness in the files installed directly alongside the .desktop files where such changes could be made directly). Effectively, then, all mimeapps.list added/removed tweaks are above all desktop file MimeTypes= lines by simple geography of directory precedence, as well as by the spec. That's sort of nice. This would give us trouble for compatibility with ~/.local/share/applications/ however, where these features are in active use today. It's also a weird arbitrary restriction. > > In order to simplify the above logic we should separate the handling of > > defaults entirely. Any language about 'default' implying 'added' should > > be removed. > > I'm ok with that. I think that the handling of defaults, on the other hand, should not pay any mind to desktop files installed at particular directories. This is something that always makes sense to inherit from the system. This is yet another reason that it makes sense to cleanly divide these concepts, I think. > > I consider it to be an open question as to what happens if Defaults > > "picks" an application that is installed but not listed as supporting > > the mimetype (either by not having it listed in the desktop file, or by > > the user having removed the association). I think this is actually not > > a very interesting question because anyone who sets something as a > > default should either make sure that it is supported (and not 'Removed' > > by user config) and/or explicitly mentioned in 'Added'. > > Yes. > > > I would even be happy to leave this implementation defined. > > I don't think we need to say that. If it's marked as default, it's > selected as > default, there is nothing implementation-specific there. I've firmed up my thinking here, as well: if we find an app that has been listed as the default for a given type, but after handling MimeTypes/Added/Removed for this mime type, we find that the app is not on the list, then we must fallback to the next default. This will nicely deal with the case of having an app listed as the default in a file in /usr while the user has removed the association entirely in their homedir, while allowing us to keep a strict separation between the concepts of added/removed and defaults. > I disagree. *That* is implementation specific. And e.g. the KDE4 code > also > cares about this order, and gives it another meaning (from most preferred > to > least preferred). In fact that is the wording I'd like in the spec. I > think it > would be ok with your interpretation, because you're simply making the > "most > recently used" the "preferred for next time", in the absence of a default > being selected (right? or maybe you just ask the user in that case...). OK. That's fine. I actually think it's a little bit weird that we use the mimeapps.list for MRU like this anyway, so I'm not about to push further on this point. > PS: about your earlier mail: multiple defaults are a MUST have > (especially in > global dirs like /usr and /etc, since in some cases the person writing > that > file has no control over which apps will be available ("compile from > sources" > distros, etc.)). I've come to agree with this point of view. Cheers _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg