Current desktop detection / app access - take 2.
michael at ximian.com
Thu May 27 16:33:07 EEST 2004
On Thu, 2004-05-27 at 12:48 +0100, Mark McLoughlin wrote:
> Ignore your immediate problems for a moment and listen.
> If we add a $DESKTOP environment variable/root window property we are
> effectively putting big sign up that says "solve all your integration
> woes here with one easy hack". No matter what we do, $DESKTOP will more
> than likely become the de-facto way of integrating apps into different
Right - hopefully it would become some sort of easy-to-use way to
distinguish which desktop to use for basic integration stuff; yes.
> Look at http://freedesktop.org/Standards for a moment and
> consider how many of those standards would exist if apps could have done:
I am still thoroughly convinced that basing your argument on some
g_assert_not_reached equivalent is rather feeble; this should/could
As any defensive programmer would do; nevertheless - since it seems you
think I am not listening - and in fact I am; let me consider these
* The formally blessed standards are rather independant of
this => irrelevant.
* Pretty good de-facto standards
+ Of these, it seems obvious that the X based desktop
interoperability standards would need to work anyway,
and are not susceptible to 'what desktop are we
ie. XDND & XEmbed, UTF8_STRING, XClipboard,
+ I guess the WM spec could have been hacked around -
but lets face it this is the reality anyway; OO.o
works around _specific_ versions of various WMs that
have misc. henious bugs anyway. (including CDE's)
+ desktop entry standardisation - an ISV/install time
issue not susceptible to 'DESKTOP'
* new but not widely used
+ menu, desktop, xsettings - desktop implementation
specs, not so relevant to apps.
+ XDS - mixed targets possible so not relevant.
+ Hackable with a DESKTOP switch:
recent files, thumbnails, startup notification,
So - yes, it is a powerful way of pragmatically generating working
software that runs and integrates well with lots of systems without
putting lots of effort into standardisation.
> I don't think we'd be better off if apps were doing this
> instead of us having well defined standardisation between desktop
> environments. And I don't believe you could think so either ...
Of course not - but then I don't think having _some_ way for authors to
detect / integrate with a given desktop is going to totally abolish any
movement towards standardisation and importantly more shared code; there
are plenty of tasks that are just not at all suitable for DESKTOP type
Ultimately - I guess, I'm interested in the user experience; from the
users' perspective I see no reason why a well architected DESKTOP based
helper-library that abstracts away eg. 'system-tray' is in any way
significantly worse than a specification. Morover, inasmuch that it is
significantly worse - there is an impetus for standardisation - so, cuts
both ways really :-)
> Notice the way I haven't mentioned your specific problems? I've put
> little or no thought into whether there is a better way of fixing those
> problems than changing behaviour based on an environment variable or
> root window property. I'm not claiming there is a better way, but if
> there isn't we should be talking about standardising on
> _NET_TOOLKIT_NAME and $DESKTOP_LAUNCH=/usr/bin/gnome-launch or whatever
> rather than introducing something which, IMHO, will introduce a
> significant barrier to us growing the number well-defined, standardised
> application integration points.
Ok; I'm most happy to re-write the proposal to using a
_NET_TOOLKIT_NAME and $DESKTOP_LAUNCH approach; since I see really no
significant difference between these and the more flexible approach that
extends to the VFS. It'd be most helpful if you could re-hash quickly
first though; eg. do you propose limiting _NET_TOOLKIT_NAME to only 2
michael at ximian.com <><, Pseudo Engineer, itinerant idiot
More information about the xdg