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, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
