New handling for URI scheme handlers
David Faure
faure at kde.org
Tue Oct 5 11:04:48 PDT 2010
On Tuesday 05 October 2010, Thiago Macieira wrote:
> Em Terça-feira 05 Outubro 2010, às 18:20:10, Aaron J. Seigo escreveu:
> > On Tuesday, October 5, 2010, Bastien Nocera wrote:
> > > The attached patch is changes to the shared-mime-info spec to mention
> > > the use of x-scheme-handler/* mime-types.
> > >
> > > Any comments?
> >
> > i suggested to use the mimetype database in a very similar way for
> > default applications (default terminal, web browser, etc). this idea was
> > denied because it was "misusing the mimetype database for non-mimetype
> > data". if this does indeed become part of the fd.o spec, can we also add
> > something in there for default apps at the same time that uses it in the
> > same/similar manner?
> >
> > if consistency reigns and this addition does not achieve consensus
> > approval, we do have .protocol files in KDE already and it would be nice
> > (and sensible) to use something that already exists instead of
> > reinventing new wheels of incompatibility.
>
> KDE would require changes anyway. Two reasons that come to mind already:
>
> 1) KDE 4 moved the files from /usr/share/services to
> /usr/share/kde4/services to avoid clashing with the KDE 3 settings
>
> 2) the same .protocol files store KIO-related information, like which
> ioslave to launch for doing data transfers and whether the
> protocol/implementation supports certain features (server-side moves, hard
> linking, etc.)
Yes, it doesn't make sense to try standardizing on our current dual-purpose
.protocol files.
I don't see any reason not to convert telnet.protocol into a
ktelnetservice.desktop with Exec=ktelnetservice %u and
MimeType=x-scheme-handler/telnet. The effort takes less time than to write this
mail (ok, almost) and I can't think of a migration issue, since the files are
installed together with the code that handles it...
What annoys me a little bit is just that at mimetype-database-generation time
we don't know which x-scheme-handler/* mimetypes are going to exist, it comes
from reading the .desktop files, which is usually done later on... This makes
the implementation more tricky than just "piggybacking the existing mimetype
implementation completely". Or are we requiring the installation of a
packages/telnet.xml mimetype definition?
Bastien wrote:
> For the default web browser, and default e-mail client, you'd use the
> handlers for the x-scheme-handler/http and x-scheme-handler/mailto
> mime-types, respectively.
I really object to x-scheme-handler/http. When you click a http URL that
points to an .odt document, you want to launch openoffice, not a web-browser. Or
at least give the option of either one, like we do in KDE ("open best app for
the job" vs "always open web browser"). But as soon as someone installs a x-
scheme-handler/http app, it will break the "open the best app" possibility.
Well, that's because I'm assuming that we'll all give priority to the scheme-
based lookup over the mimetype-based lookup, since the primary goal is to
handle schemes where mimetypes don't even make sense, like mms:/, feed:/,
telnet:/. In KDE we actually quite a number of these: mailto, mms, mmst, mmsu,
pnm, rlogin, rtsp, rtspt, rtspu, ssh, telnet, aim, callto, feed, news, magnet,
irc.
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the xdg
mailing list