hi Simon, Thanks for writing all of this up.
I have only one concern below (and it's sort of a hand-wavy thing that I'd appreciate more feedback on). On Mon, Jun 20, 2016, at 13:24, Simon McVittie wrote: > One subtlety of the phrasing is that a single .desktop or .service file > might be visible in more than one directory thanks to symlinks, hard > links or bind mounts. Thiago's phrasing makes it specific that it is the > directory that actually appeared in the .desktop or .service search path > that matters, and not any of the same file's other apparent locations. It must be this way, at least for hardlinks, since there is no way to tell which one is the "real" one. I don't think we should be speaking about search paths, though, because it may confuse the issue. What happens, for example, if my homedir contains a symlink to a desktop file in /usr/share/applications? Reading "search path" here makes me think that maybe I need to be more intelligent about how I treat this: do you really intend for me to check if the destination of the symlink is in one of the standard directories and proceed accordingly? This is a no-go. On the other hand, what we are doing here very much might break the previously working behaviour of making symlinks from /usr/share/applications into the user's home directory. We might imagine that a user has a collection of their favourite apps in some folder on their desktop, and an app changes to a relative path scheme in their Exec= line on an upgrade, breaking the user. That was not possible before, but with this change, we make it possible, so in a sense, this could be viewed as a break. On the other other hand, if we follow this all the way down the rabbit hole, we may get into weird situations whereby we're canonicalising symlinks in situations where /usr is a symlink to /mnt/usr or something equally awful, in which case we might end up at the wrong result. For that reason, I think we should limit any resolution step here to direct inspection of the desktop file in question for being a symlink, itself, and not attempt a full canonicalisation. tl;dr: for ease of implementation I lean toward "do the dumb thing" and for user-friendly I lean toward "do the hard thing". Overall, I think we should do the 'hard' thing, mostly because we only have to pay the extra cost of the path canonicalisation in case we find a relative path on the Exec= line. In any case, I do not support any reference to or mention of "search path". > For the somewhat obscure feature in which > ".../applications/foo/whatever.desktop" is equivalent to > ".../applications/foo-whatever.desktop", I don't really care whether the > relative path is relative to .../applications or .../applications/foo. I > would go for .../applications if I have to make an arbitrary decision, > but I believe this feature was added to support something in KDE, so > I'll defer to whichever one KDE developers would prefer. I strongly suggest that this case is resolved relative to the directory in which we found the actual file. It should always be possible to find a bare desktop file in a random directory and run it directly, without having to guess that this directory may be a subpath of the search path. Thanks again for the excellent write-up. Allison _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
