Adding new key Classification to desktop-entry-spec

[Simon McVittie]

On 09/01/15 05:52, Genghis Khan wrote:
> The purpose of key Classification is for Default Applications
> management software to recognize what type of application a desktop
> file represents.

Without a concrete list of classifications, we can't really have an
informed opinion on whether this is an already-solved problem, and if
not, whether this is an appropriate solution.

What classifications do you have in mind, other than file manager and
web browser? http://git.xfce.org/xfce/exo/tree/exo-helper/helpers also
seems to include terminals and MUAs; is there anything else?

I can't help thinking that we probably have this information already, in
some form or other.

gnome-control-center 3.14 manages to offer lists of applications for
Web, Mail, Calendar, Music, Video and Photos without having this
infrastructure, and I think earlier versions offered a choice of
terminal emulators too. It determines the current default by asking the
MIME-type infrastructure what the default handler is for:

* x-scheme-handler/http
* x-scheme-handler/mailto
* text/calendar
* audio/x-vorbis+ogg
* video/x-ogm+ogg
* image/jpeg

The first one and the last three are a representative member of a class
of MIME types, because there might not be a unique answer to "what is my
default for audio files?" if you don't do that.

If a new default is selected, g-c-c will set the web browser as the
default for every MIME type it supports (specifically intending to
affect all of text/html, application/xhtml+xml and
x-scheme-handler-https), or set the music/video/photo app as the default
for every audio/*, video/* or image/* MIME type it supports. This seems
a reasonable implementation of its UI design.

The GNOME UI design for default apps doesn't include a selectable file
manager, but Nautilus does advertise itself as a handler for
inode/directory, so file managers could work the same way if desired.

Terminal emulators are harder, because not every terminal emulator has
the same command-line API. In Debian the standard for the
x-terminal-emulator alternative is "must handle a certain subset of
xterm options" for the obvious historical reason, and we have wrapper
scripts around GNOME-derived terminals (and probably other desktops'
terminals too) to implement xterm's "xterm -e" semantics in terms of
GNOME Terminal's separate -e and -x options.

If all you need is "open an interactive terminal in $directory",
executing any .desktop whose Categories include TerminalEmulator with
$directory as its current working directory would probably do the right
thing. If you need the equivalent of 'xterm -e $argv0 $argv1...' or
'xterm -e $shell_command_line' then you get to deal with the
command-line compatibility concerns outlined in
<http://lists.freedesktop.org/archives/xdg/2014-January/013126.html>.

    S