protocol/scheme entry in .desktop?

David Faure dfaure at
Thu Jun 26 08:11:36 PDT 2008

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
> 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, sponsored by Trolltech to work on KDE,
Konqueror (, and KOffice (

More information about the xdg mailing list