Current desktop detection / app access - take 2.

[Michael Meeks]

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

* Abstract

	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
technology.


* Specification

	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):

	Toolkits:
		gtk, motif, qt, 

	File Access:
		gnome-vfs, kio

	Complete environments
		antiright, cde, enlightenment, fluxbox, fvwm,
		gnome, gnustep, icewm, kde, rox, tkdesk,
		windowmaker, xfce

	Element names must contain only lower-case alpha/numeric
characters using the ASCII.

* Examples

	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:

	DESKTOP="kde:kio:gnome-vfs:qt"


* 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;
	done
	# fallback to system-specific default:
	/usr/bin/desktop-launcher/<default desktop> $@ && exit 0
	exit 1

	It is anticipated that each desktop can simply install a
script eg.

              /usr/bin/desktop-launcher/rox

	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:

	--mime-hint="<mime/type>"
	    + 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 \
			     --mime-hint=application/vnd.ms-excel

* another sub-heading

	< this space left deliberately not blank >

	Regards,

		Michael.

-- 
 michael at ximian.com  <><, Pseudo Engineer, itinerant idiot