.desktop file: supported URL schemes key
mpyne at kde.org
Wed Nov 17 14:36:50 PST 2010
On Wednesday, November 17, 2010 13:58:28 David Zeuthen wrote:
> 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.
Um, I thought the whole purpose behind URLs is that they are supposed to be a
uniform way to locate a resource. This *should* mean that they work in
different applications, even wildly different ones.
I will grant your point that having a dedicated, trusted, secure application
for handling password management is much better than having it across
different applications. But that's a very lame reason for disabling the other
99.9% (or so) of URL uses.
As in David's example of VLC, how often is it that opening up an http:// or
ftp:// URL should require authentication?
I can't speak for others in KDE but just as a general principle I wouldn't say
we're opposed to FUSE per se, but opposed to making it a required dependency
for network I/O to work at all between different applications. I don't know
that GNOME is targeting any other desktops for example, but does GNOME VFS
really not work at all on Windows or OpenBSD? (Two OSes that from what little
I can tell have no FUSE support). KIO already handles the issue of
authentication for instance, so it's not like we have to worry about
applications stealing passwords that way (I make no claims as to how many
security best practices are used in that handling -- but that is orthogonal to
Obviously that doesn't matter when launching Evince from Dolphin or Kaffeine
from Nautilus... but it's still orthogonal to this discussion. I actually
rather like the idea of centralizing authentication concerns (as in some kind
of auth-agent similar to ssh-agent or gpg-agent) but I'm really not seeing how
that's relevant to UrlSchemes in the Desktop Entry spec.
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the xdg