Genghis, > Please pardon me for being unclear.
I did not think your posting unclear, but the details need to be worked out and described unambiguously before a new file sub-type can be added to the spec. The existing specification could use some improvements in this area (see below). > I have answered to your queries, but, if you may, please > elaborate on the following part of your message: >> so is it intended purely for the "application" argument of >> "xdg-mime default"? If not, what does it do? In my (limited) experience adding a desktop file with a MimeType line does not register a new MIME data handler with the Desktop system. In fact it seems to have no effect at all. I have tested KDE, Unity and (IIRC) GNOME. To add a handler, the "xdg-mime default" must be used to associate the MIME type with the desktop file. The spec says this about the MimeType key: The MimeType key is used to indicate the MIME Types that an application knows how to handle. It is expected that for some applications this list could become long. An application is expected to be able to reasonably open files of these types using the command listed in the Exec key. There should be no priority for MIME Types in this field, or any form of priority in the desktop file. Priority for applications is handled external to the .desktop files. That suggests that there is no requirement for the key to do anything by itself. > Indeed, there is no Exec key, only Link key, and such launchers > would be activated with a default web browser, similarly to entries > of Type=Link. >> The meaning of the Link item is unclear. The spec defines the >> %u substitution as handling a URL, but yours is already in the >> tail of a URL. > Yes, this is because I did not figure of a better way to realize it, > so I did it in a similar manner to how it is done within web browsers > with what is known as "smart bookmarks". See http://ptaff.ca/smart/ My French is not great, but if I interpreted that correctly, you are proposing nothing more than a parameterised variant of a Link desktop file. That seems a good idea, but it is not clear that it needs a new sub-type. Have you considered the alternative of extending the Link format? I notice that the current spec does not describe the expected behaviour of Link and Directory files at all! Thanks, Giles -----Original Message----- From: Genghis Khan [mailto:[email protected]] Sent: 07 January 2016 8:39 AM To: Giles Atkinson Cc: [email protected] Subject: Re: RE: Type=Webapp Hello Giles, Please pardon me for being unclear. I have answered to your queries, but, if you may, please elaborate on the following part of your message: > so is it intended purely for the "application" argument of > "xdg-mime default"? If not, what does it do? See rest of message below. > Sent: Wednesday, January 06, 2016 at 5:34 PM > From: "Giles Atkinson" <[email protected]> > To: "'Genghis Khan'" <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: Type=Webapp > > Genghis, > > I think this needs additional explanation. My guess is that > such entries are not expected to be visible (NoDisplay=true), > so is it intended purely for the "application" argument of > "xdg-mime default"? If not, what does it do? > Yes, mostly, but not exclusively. Such entries are mostly to be used with invoking protocols such as irc://, sip:, tox:, xmpp: or files such as ODT, TXT etc. Yet these entries may also be used as standalone launchers and, as such, are to be visible (NoDisplay=false). > How do you expect a Desktop File of this type to be activated? > What do you expect to happen when such an entry is activated > (there is no Exec key)? > Indeed, there is no Exec key, only Link key, and such launchers would be activated with a default web browser, similarly to entries of Type=Link. > The meaning of the Link item is unclear. The spec defines the > %u substitution as handling a URL, but yours is already in the > tail of a URL. > Yes, this is because I did not figure of a better way to realize it, so I did it in a similar manner to how it is done within web browsers with what is known as "smart bookmarks". See http://ptaff.ca/smart/ > Thanks, > > Giles > > -----Original Message----- > From: xdg [mailto:[email protected]] On Behalf Of Genghis Khan > Sent: 06 January 2016 11:47 AM > To: [email protected] > Subject: Re: Type=Webapp > > This might also be used for editing documents with online > word processors or spreadsheet editors etc. > > > Sent: Tuesday, January 05, 2016 at 6:43 AM > > From: "Genghis Khan" <[email protected]> > > To: [email protected] > > Subject: Type=Webapp > > > > Hallo, > > > > > > I would like to propose a new type of Desktop shortcut. > > > > Type=Webapp > > > > Instead of having to repeat a Register Protocol Handler > > procedure to add a "webapp", I suggest to create a .desktop > > file to directory .local/share/applications/ instead of or > > in addition to this procedure for two reasons: > > > > 1. Not to have to repeat this procedure with every web > > browser. > > > > 2. The ability to access a "webapp" with a click on a > > hyperlink in applications that are not web browsers. > > > > Referring to API: > > window.navigator.registerProtocolHandler(protocol, uri, title); > > > > Type=Webapp is mostly, if not solely, intended for > > associating web browsers with protocol MIME types. > > > > Example Desktop Entry File (KiwiIRC as an example) > > > > [Desktop Entry] > > Version=2.0 > > Type=Webapp > > NoDisplay=true > > Name=KiwiIRC > > Comment=Chat over the Internet Relay Chat network > > Link=https://irc.freedesktop.org/%u > > Icon=kiwiirc > > MimeType=x-scheme-handler/irc; > > Actions=Nickname;Register;MOTD; #actions might be useful > > > > Please post your opinions and thoughts. > > > > > > With regards, > > --GK > > > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
