protocol/scheme entry in .desktop?

[David Faure]

On Monday 26 November 2007, Patrice Dumas wrote:
> Hello,
> 
> Currently the mime information that allows to chose an application based
> on the mimetypes it handles is part of the .desktop file. But another
> item of an url that could be a criterium for application selection is the
> protocol/scheme that appears in front of urls, like http, ftp or file. 
> So maybe it could be nice to add a new entry in the desktop entry,
> called Protocol or Scheme, with a ; delimited list of protocols handled
> by the application.
> 
> This solves a real use case (well, in my opinion), taking pdf as an
> example, evince handle http url while xpdf doesn't, still evince isn't 
> a generic browser (like firefox, for example). So this seems to me
> to be an interesting application property to exhibit.
> 
> In that case it may be relevant to add a fake mimetype that stands for
> 'any content' such that if an url has no discernible content is still
> handled by an application. For example an url like
> http://somewhere.com
> or a complex one with cgi/target and so on, and so forth would be
> handled by such application. Typical application for this kind of urls
> (miometype) would be browsers(firefox, konqueror...). I guess that 
> mimetypes are outside the scope of the freedesktop desktop specification, 
> but I nonetheless described this because I think that a way to specify
> a generic browser should be possible within that framework.
> 
> Another possibility would be to add a fake mimetype for the protocol,
> like x-url/http, but the issue with this, in my opinion, is that it adds
> a new semantic to the mimetype which are normally only for content, and
> also it doesn't allow to specify both the mimetype and the protocol.

I implemented something like this in KDE some time ago. Not for application desktop
files, even though it'd be a good idea to have it there too, but I implemented it in
the service desktop files for dolphin/konqueror, called servicemenus. In those files you can say
X-KDE-Protocol=<one protocol>, or X-KDE-Protocols=<list of protocols>, or use !http to exclude http.

Hmm I thought I implemented it for application desktop files too, but now I can't find that code anymore. Memory overload :)
I had the idea of supporting X-KDE-Protocols=<list of protocols> or X-KDE-Protocols=KIO for "all protocols supported by KIO".
Of course the problem is that this is hard to standardize; if we said in the desktop entry standard that you
can write Protocols=KIO then how would non-kde apps know what protocols this means exactly...

Anyway, I agree with Patrice's suggestion, (despite the huge delay between his post and mine :) ),
let's start by solving the simple case first; apps where we can explicitely list the supported protocols, no plugins involved. I suggest an optional
Protocols=<list of protocols> key in desktop files, where of course the query for applications should look like:
"search for desktop files that have $mimetype, AND (no Protocols key OR Protocols contains $protocol)".

Up to now we could only differenciate based on "Exec key contains %u/%U => it supports all protocols"
but that's not good enough obviously.

Any objections from other desktop environments?
Who can make changes to the desktop entry standard?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).