.desktop file: supported URL schemes key
pcman.tw at gmail.com
Wed Nov 24 05:47:14 PST 2010
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 <zeuthen at gmail.com> wrote:
> On Wed, Nov 17, 2010 at 9:26 AM, David Faure <faure at kde.org> 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-
>> 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 .
> 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.)
>  : GIO is designed to support a trusted path for password entry - see
> 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
> xdg at lists.freedesktop.org
More information about the xdg