Current desktop detection / app access ...

Mark McLoughlin markmc at redhat.com
Fri May 7 16:39:21 EEST 2004


Hi Michael,

On Thu, 2004-05-06 at 12:03, Michael Meeks wrote:
> Hi guys,
> 
> 	Just wondering if it would be possible to standardise on a desktop
> detection method, that would work well for all relevant desktops; there
> are two places in the OO.o code where this causes us pain:
> 	* toolkit integration
> 		+ extensive random X property pokeage,
> 		  WM name sniffage etc. unreliable & fragile
> 	* helper application spawning
> 		+ no detection, each distro patches this one way
> 		  or the other, for mailto: / http: / whatever - and the
> 		  defaults are hard-coded.
> 
> 	So - possibly this is standardised already; otherwise a proposal
> something like this might work:
> 
> 	* DESKTOP environment variable:
> 
> 	This is a ':' delimited symbolic path of desktop technologies, this
> complexity is to allow for the myriad desktops out there built on top of
> various different bits; eg.
> 
> 	DESKTOP=kde:qt, DESKTOP=rox:gtk or DESKTOP=gnome:gnome-vfs:gtk
> 
> 	This environment variable can be parsed by eg. OO.o to work out which
> toolkit to integrate with in a sane way.

	I've had a request for something like this before in gnome-session. It
worried me then, and it still worries me now.

	In most cases, I think there are better solutions to these types of
problems than switching your behaviour based on the desktop environment
you're logged into. I don't know about your problems specifically and I
suspect there may *not* be a better way, but I'm loathe to create a
generic cop-out mechanism for everyone who comes up against these types
of problems.

	Basically, given that there is no better solution to your problem, I'd
much prefer to see something like

  + $DESKTOP_OPEN environment variable contains the name of the "open"
    script which should be used under this desktop environment

  + desktop-open script would just launch the script specified by 
    $DESKTOP_OPEN falling back to the vendor specific one if not found.

Cheers,
Mark.





More information about the xdg mailing list