[New] Desktop Preferred Applications Specification
pcman.tw at gmail.com
Sat Jun 13 01:25:31 PDT 2009
On Mon, Jun 8, 2009 at 4:31 PM, Brian J. Tarricone<bjt23 at cornell.edu> wrote:
> On 06/06/2009 10:52 PM, PCMan wrote:
>> Here is the full specification.
> Aside from other objections raised, I see a problem with your terminal
> handling. You suggest specifying something like this in the .desktop file:
> Exec=gnome-terminal -e %f
> ... except that won't really work. If the user tries to launch the
> terminal from, say, the applications menu, it'll fail to load because
> the menu implementation will try to execute "gnome-terminal -e".
> gnome-terminal may behave ok if you pass -e without any parameters, and
> it may not... regardless, poor command-line option parsing isn't a
> 'feature' you can rely on.
So maybe we should either force all xdg compliant terminal emulators
to support -e option, or we can add a seperate key in the desktop file
for this purpose.
> Also the terminal emulator option lacks a method to do something I
> imagine might be common -- opening the terminal emulator with $PWD set
> to a directory specified on the commandline (of course, you could do
> fork(); chdir(); exec(); but that's kinda lame).
fork + chdir is a simple and effective solution which doesn't need any
modification to existing specs. Personally I'm ok with it, and we use
this approach in our LXDE, too.
> Not sure what the best way would be to handle this... maybe through some
> custom X- prefixed keys in the desktop file, like
> X-Terminal-Run-Command-Exec= and X-Terminal-Open-Directory-Exec=. (Of
> course, this would be a perfect job for the 'custom actions' portion of
> the desktop entry spec; a pity that was removed and there's no good
> replacement; Thunar implements it, and IMO it's pretty useful.)
How can you express the $PWD in X-Terminal-Open-Directory-Exec?
This doesn't solve the problem and further complicate the spec.
So I think for dirs, fork + chdir is the standard way, and for
executing programs in terminal, an additional X- prefixed key is a
> Otherwise I'm ok with most of this.
> One other thing -- why is there a need for a special
> application/x-web-browser fake mime type? Why not just use
> application/x-xdg-protocol-http and application/x-xdg-protocol-https?
> Is there enough value in knowing that an app is a web browser (rather
> than just "an app that handles http/https URLs") that would justify a
> special case?
You are possibly correct as I haven't found any real special cases.
On Windows the default web browser is the protocol handler of http, too.
More information about the xdg