Current Desktop capabilities - take 3.

[Michael Meeks]

Hi Mark,

On Sat, 2004-06-05 at 13:06 +0100, Mark McLoughlin wrote:
> > 	"I'd love to get some feedback from the people most vehemently opposed
> > to the initial idea"
> 
> 	One of two things is going on with your "take 3" proposal:

	:-)

>   a) You're deliberately proposing something which you know to be 
>      inescapably horrendous in the hope that we'll see the error of our 
>      "unhelpfully perfectionist" ways and go running back to your
>      original proposal or

	Not at all - I'm deliberately removing the straw man of:

	switch (foo)
		case GNOME: / case KDE: [ omitted CDE etc. ]

	which was the basis of, well virtually every argument I listened
carefully too against it; [ and is rightly labeled as a terrible idea,
no-one should be switching for anything on desktop name; but instead
it's capabilities ], and I'm accomodating your DESKTOP_LAUNCH proposal;
and Havoc's DESKTOP_BUTTON_ORDER (?) alternative.

	I'm not convinced that DESKTOP=a:b:c is any more inescapably horrendous
than DISPLAY=host:disp.screen. So - I'd appreciate more detailed
criticism, I attach the revised proposal to make this easier.

>   b) You've gone battshit insane.

	:-) lol, that's probably true, if only the voices in my head would keep
quiet long enough for me to think straight. Having said that I'm in the
good company of Waldo, George, and well - ISVs who actually have to deal
with these problems now, and don't want to wait for the Star-Trek-Future
for some perfect solution [ which is in no way precluded by the short-
term hack =].

> 	Ultimately, of course, all extremely amusingly
> transparently tongue-in-cheek ...
> Love,

	Of course; and taken that way. I guess I'm grateful for the response -
but any chance of a more detailed critique ? I _think_ I managed to
respond and incorporate much of the last round of comment, but I'd love
more input.

	Regards,

		Michael.

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

-------------- next part --------------
* 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 different desktop interfaces. This specification presents
a simple way for applications to detect various preferred technology
sets for use in desktop integration.


* 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 '_NET_DESKTOP' root window string, X property on screen
	   0 if the environment variable 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, 

	Button order:
		button-corner, button-inset

	File Access:
		gnome-vfs, kio

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

* Examples

	In many cases, we would expect to see eg.

	   DESKTOP="button-inset:kio:qt" or perhaps
	   DESKTOP="button-corner: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="button-inset:kio:gnome-vfs:qt"