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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
