If these things never works as expected, what's the point in using URIs in the command line? The Exec key of the desktop entry spec allows the use of %u and %U. If file:/// is the only scheme which really works, why bother using URIs here? It's fine to support %f and %F, and ask everyone to use FUSE. If we allow the use of %u and %U, than it's necessary to make sure it can work for the purpose. Since protocol handlers can be added to the system now, this is crucial. If a URI scheme can be supported by two different apps, and they treat the URI differently, this still causes bad user experience. So URI scheme is a real issue which cannot be circumvented simply by using FUSE.
On Thu, Nov 18, 2010 at 2:58 AM, David Zeuthen <[email protected]> wrote: > Hi, > > On Wed, Nov 17, 2010 at 9:26 AM, David Faure <[email protected]> wrote: >> OK. Good for you :-) >> Can I still request that we add the key to the .desktop files? >> It is very much needed, for any implementation that doesn't use the FUSE >> trick. Surely you're not saying that implementors of the desktop entry spec >> must use FUSE absolutely? >> >> For instance I need to ask the VLC guys to add the information about the >> supported protocols in their .desktop file, this would be made much easier >> if I >> can ask them to add UrlSchemes=... than if I have to ask them to add X-KDE- >> Protocols=... >> >> So, can I add UrlSchemes to the spec? You're free to ignore it in GIO :) > > Actually, sorry, but I'm still opposed to adding this to a > freedesktop.org specification. Here's why: The problem is that it will > never really work properly because *unless* you use the same code in > both applications, e.g. > > 1. the interpretation of the given URL is the same in both apps > 2. both apps have access to the same pass-phrases / cookies > 3. the end points actually support more than one initiator > (e.g. more than one login for e.g. network shares) > > In reality, we found over the last ten years in GNOME that this never > is the case and we found that things never really worked. Unless, of > course, both apps are using *exactly* the same code. > > Heck, for example, the GVfs interpretation of ftp:// greatly differs > from that in e.g. your Web Browser. And smb:// usually requires > login/passwords. So the user gets to enter his password once in, say, > the file manager (when setting up the share) and then again (in a > different looking dialog!) when using the app (e.g. VLC or mplayer). > That's just a really bad experience. > > Further, for password hygiene you don't want your dot-files in $HOME > littered with passwords for all your different apps. Further, you > don't want randomly written password dialog code of dubious quality > (e.g. not zeroing memory) to run - instead, ideally, you want to > request the password via a *secure* and *trusted* path so even the > requesting app cannot steal the password [1]. > > On the other hand, these problems don't exist when using FUSE. For > example, it would make GIO apps work (and all other apps too) a lot > better when launched under KDE since they would be able to reuse the > same connection and thus not re-prompting the user for passwords. It's > just 1000 times easier. So I'm not sure why you are so adamant about > not using FUSE in KDE - I mean, if you don't you're signing the user > up for these problems. > > So, based on this, I'm against adding UrlSchemes to the spec since it > will lure people into believing that exchanging URLs between *wildly* > different apps works. While the reality is that it really won't work > at all. > > (btw, feel free to exchange "use same code" above with "implement > exactly the same behavior (e.g. URL scheme semantics), use same file > formats, locking, password store and so on. Which, to just cover the > mainstream protocols, would be hundreds of pages of fd.o specs, lots > of conformance tests, etc. etc. Sorry, but it's totally unrealistic we > can do that here in the freedesktop.org project.) > > Thanks, > David > > [1] : GIO is designed to support a trusted path for password entry - see > > http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html > > and surrounding messages. We might even implement for GNOME 3 since > all password dialogs will be system modal (so they look more like the > OS and less like each app) and probably run in the shell process > (which we can put in a different security context or something so > normal apps can't get the passwords out via e.g. ptrace()) > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
