Current desktop detection / app access - take 2.
michael at ximian.com
Mon May 17 18:31:57 EEST 2004
On Thu, 2004-05-06 at 14:45 +0200, Waldo Bastian wrote:
> Sounds simple enough, if you write it out in a spec doc, I will
> add support in KDE for it.
So - I spent a few more minutes plumping up the proposal,
adding a great long list of desktops I never new existed from the
fd.o list etc. Having looked at recent specs on fd.o - I see they
are all deeply XML-ized; is this a pre-requisite for acceptance ?
since it looks pretty painful.
Anyhow - the blurb looked like this: I guess I know nothing
concrete about X properties - I just thought I'd add that; potentially
and/or arguably which one is canonical is an interesting discussion.
Also, I know nothing about the LSB and recommended paths etc. is
/usr/bin/desktop-launchers an adequate place to standardise on ?
Finally - I guess, there is prolly some fruitful
standardisation of the myriad 'mailto:' options that we could pass
wrt. attachments, CC's BCC's etc. etc. ;-) that would be useful for
OO.o too; but I'd rather get a first cut 'approved' if indeed there
is an approval process, first.
Anyhow - advice appreciated;
* Detecting desktop capabilities
When applications wish to integrate well with different
desktop technologies, one approach is standardisation of every ISV
interface; another is to allow an application to detect, and integrate
with several types of interface. This specification presents a simple
way for applications to detect various preferred technology sets for
use in desktop integration.
This specification also presents a way to launch the correct
application to handle a given URI based on this desktop hinting
An application has two ways to detect what desktop environment
it is running under, before it falls-back to some best-guess / default
mechanism. This mechanism forms an advisory (or 'hinting') function
only, many applications should never care about this variable.
a) the 'DESKTOP' environment variable - this should be the
primary source of desktop information or
b) the 'DESKTOP' root window X property if it is not set.
The 'DESKTOP' variable will take the form of a : separated
ordered list of technologies; with preferred mappings occuring from
the initial to the final elements.
* Defined Elements
Clearly many technologies could be annotated and ordered in
the DESKTOP string; and we encourage this, however it is important to
ensure that a sufficiently unique name is chosen, and (preferably)
added to this specification.
Registered technologies & names (alphabetical order):
gtk, motif, qt,
antiright, cde, enlightenment, fluxbox, fvwm,
gnome, gnustep, icewm, kde, rox, tkdesk,
Element names must contain only lower-case alpha/numeric
characters using the ASCII.
In many cases, we would expect to see eg. DESKTOP="kde:kio:qt"
or perhaps DESKTOP="gnome:gnome-vfs:gtk", however more complex
scenarios should be tolerated; for example - if a user was concerned
that a more powerful file access layer was used if available, but
preferring kio to gnome-vfs they might specify:
* Application launch
In order to allow an application to use the most appropriate
helper application to launch a viewer for a given URI, it is proposed
that we have a small script that bootstraps from this DESKTOP setting.
This script shall be in the system path, called 'desktop-launch' it's
essential algorithm should be that of:
# attempt to use $DESKTOP
for a in `echo $DESKTOP | sed 's/:/ /g'`; do
/usr/bin/desktop-launcher/$1 $@ && exit 0;
# fallback to system-specific default:
/usr/bin/desktop-launcher/<default desktop> $@ && exit 0
It is anticipated that each desktop can simply install a
that will filter off whatever URIs they can handle, returning
a status of 0 if handled, otherwise non-zero.
* desktop-launch arguments
In addition, there are a few optional arguments, that should
be standardized to such a launcher; with a defined syntax:
+ This specifies an optional hint to the launching
application as to the mime-type of the data, to avoid
repeated sniffing; eg.
desktop-launch file://foo/baa.xls \
* another sub-heading
< this space left deliberately not blank >
michael at ximian.com <><, Pseudo Engineer, itinerant idiot
More information about the xdg