[New] Desktop Preferred Applications Specification
rcvxdg at gmail.com
Mon Jun 15 08:59:44 PDT 2009
"Aaron J. Seigo" <aseigo at kde.org> écrivit:
> On Saturday 06 June 2009, PCMan wrote:
> > Here is the full specification.
> > http://wiki.lxde.org/en/Desktop_Preferred_Applications_Specification
> using the mimetype database with entries crafted for default applications is
> something i suggested 2-3 years ago at a few cross-desktop events, including a
> FUDCon. i think it is the least-distance solution for the problem of default
> applications, and so support that part of the proposal.
> i would suggest changing application/ to something like x-default-application/
> as that makes it blatantly obvious what it is rather than pollute the
> application/ group. perhaps this violates some mimetype db rule though?
> however, i don't think that URI schemes should be brought into this, nor is
> there a real need to imho.
> for example, the application or desktop knows best when it wants to open
> something in a web browser or not, and it often has absolutely nothing to do
> with the protocol involved.
> for example, http://mysite.com/foo.pdf will open in Okular not the web browser
> in KDE.
IMO, default applications and URI handlers are very different things.
For example, a mail client is more than just an application handling mailto URI.
Typically, a mail client can send (mailto) AND receive mail. An application automatically registering a user on a web site could launch the default e-mail client to let the user see the registration confirmation e-mail.
Similarly, a Web Browser, is more than a HTTP handler. That explain why PCMan, instinctively or deliberately defined Web Browser as application/x-xdg-web-browser rather than application/x-xdg-protocol-http.
The later type includes wget and curl...
Typical use cases of default browsers are:
Displaying remote text/plain documentation stored on FTP or HTTP site.
Displaying remote HTML documentation (using default browsers as HTTP + HTML clients).
Displaying local HTML documentation (file:// + HTML client).
Displaying local or remote XHTML.
Provide a "launch browser" button in some toolbar interfaces.
Whatever abstractions are defined, I think the user should be able to choose his default application once and see it being used everywhere.
Consequently, even if the multiple functions of a web browser are split in different abstractions (e.g. application/x-xdg-protocol-http+html; application/x-xdg-protocol-http+xhtml; text/html; application/xhtml+xml ...), the user shouldn't have to specify his default browser for every protocol or file format it supports. Even if the desktop environment might give some ways to define more specific types of default applications, these subtypes should default to the default browser unless the default browser doesn't support a specific protocol or file format.
> so i'm all for the shared default apps (and would be happy to implement it in
> kde 4.4, even, pending approval from my fellow KDE devs) but think the URI
> sections should be dropped.
Indeed, the URI section is something different.
Bastien Nocera wrote:
> Yes, but we'd still be missing metadata to tell us how to construct the
> commands to launch those mailers with attachments.
What about writing a shell script for every mailer, web browser and terminal emulator to make them conform to a standard command line interface FDO would define for each type of application?
More information about the xdg