On Sat, 22 Dec 2018 at 20:06:26 -0800, Ross Vandegrift wrote: > On Sat, Dec 22, 2018 at 11:41:20PM +0000, Simon McVittie wrote: > > While researching this in codesearch.debian.net I found that e17 > > (Enlightenment) still sets the user-preferred file manager by setting > > it as an x-scheme-handler/file handler. e17 maintainers, please > > don't do this: the interoperable freedesktop.org pseudo-MIME-type > > for a general-purpose file manager like Nautilus, Thunar, Dolphin > > or (presumably) enlightenment_filemanager is inode/directory, and > > enlightenment_filemanager's desktop file already announces it as an > > inode/directory handler. > > Untested patch attached. I'm travelling the next week and may not have time > to > test/package until January.
I don't use enlightenment myself, but the patch looks like what I had in mind. > I don't know the fdo specs well, but this behavior of x-scheme-handler/file > seems like a pretty bad misfeature to me. Does it exist only for the gdm3 > use-case? x-scheme-handler/file isn't really a feature at all, more a consequence of a more general feature that *is* useful. It makes a lot more sense to set a handler for all mailto URLs (for example associating Evolution or Mutt with x-scheme-handler/mailto), or for all rtsp URLs (for example associating a media player with x-scheme-handler/rtsp), or for all xmpp URLs, or any other single-purpose URL scheme. x-scheme-handler/http for general-purpose web browsers like Firefox and Chromium is perhaps a bit more of a stretch (because there are lots of things you can do over HTTP that aren't browsing the web interactively) but still makes some sense, because if you have a http URL out-of-context and you are told to open it, what else would you do with it other than open a web browser? But setting a single handler for all of x-scheme-handler/file is only ever going to block useful functionality, because it's a much broader match than anything you'd want to do under normal circumstances. gdm3 uses x-scheme-handler/file because it *wants* to block useful functionality: the idea is to make sure there is no way to trick the greeter session into opening a normal application. This is exploiting a side-effect of a consequence of the x-scheme-handler design, more than something that was designed in. Whenever a design provides a very general mechanism, there will be things you can do with that mechanism that don't really make sense. For instance, POSIX scripts start with #! and the path to an interpreter, so if you wanted to, you could write a #!/bin/rm script that deletes itself, or a #!/bin/cat script that is a quine; either would be pointless, but both are just as valid as a #!/bin/sh script. smcv