Current desktop detection / app access
michael at ximian.com
Thu Aug 12 12:02:57 EEST 2004
On Wed, 2004-08-11 at 18:59 +0100, Mark McLoughlin wrote:
> > I guess we're going to have to support that going forward instead of
> > something far more structured, pleasant and standardised.
> We had a private email discussion in June where I was left with the
> feeling that
> a) you had re-read the original mails and now understood the reasons
> why we thought that a "hang your hack here" $DESKTOP environmental
> variable would do more harm than good
Well; possibly I've forgotten; As I recall it was about encouraging the
creation of new library/data standards etc. by avoiding the easy - huge-
bang-for-little-buck approach now. Possibly I forgot which explains my
annoyance. As I recall, perhaps we got to some mid-way point where
people were prepared to accept some compromise like some X property
specifying the preferred toolkit, file-selector, print dialog, button
order etc. - was that so ?
> b) you understood that ignoring the point people were trying to make
> and doing things like accusing them of "acute willingness to
> assist" just frustrates any possibility of having a productive
I guess I'm just horribly frustrated by the lack of progress / positive
interest when it comes to formalising something useful. Sorry for being
> c) you were going prepare a specification for a solution to your
> specific problem along the lines of $DESKTOP_LAUNCH or the solution
> Waldo proposed
Yes - however that addresses a _tiny_ piece of the puzzle; and indeed
we're using DESKTOP_LAUNCH for that piece in NLD ( or in fact, more like
The problem is; I've written a prototype new spec. for that (attached),
but havn't been able to grok the URI format / mangling / syntax for the
mailto: URI - which we need to specify to make it actually useful - so
it's essentially rotting unfinished on my disk.
Also - I'd love to get the setenv ("DESKTOP_LAUNCH=gnome-open") patch
into Gnome 2.8's gnome-session, but - can't face the effort at this
stage in the process; so had essentially given-up on the whole thing for
another 6 months.
michael at ximian.com <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
* Launching desktop URI handlers
2004/07/27 - Michael Meeks & Jan Holesovsky
It is often useful for an application to allow the launching
of a helper application on the same screen to display a URI. This
method provides a simple mechansim for achieving this in a
cross-desktop compatible fashion.
+ The desktop session environment will include a
DESKTOP_LAUNCH environment variable.
+ The session path shall include a binary named
'desktop-launch' that initially attempts to
execute the contents of $DESKTOP_LAUNCH
passing on to it any provided arguments.
** In more detail
The DESKTOP_LAUNCH environment variable should point to an
executable with as little system-specific qualification as possible.
ie. 'kde-open' is preferable to /opt/kde3/bin/kde-open since it is
more likely to transfer to a more diverse range of (possibly remote)
The desktop-launch binary can adopt other strategies for
detecting the current desktop, and appropriate handler to execute -
however it must initially attempt to execute the $DESKTOP_LAUNCH
variable. The desktop-launch must return a status code to indicate if
the launch succeded; in the normal fashion.
** Special URIs
Handling a mailto: URI creates a number of issues, primarily
the encoding of the various extra fields such as cc:, subject: etc.
The proposed standard encoding is that of a number of parameters
eencoded in the normal way into a URI; common parameters being:
'from', 'to', 'cc', 'bcc', 'subject', 'attachment', 'body', where the
'cc', 'bcc' and 'attachment' fields may be enumerations delimited by
the ';' character.
... Check / continue ...
More information about the xdg