Current desktop detection / app access - take 2.

[Michael Meeks]

On Thu, 2004-05-27 at 12:48 +0100, Mark McLoughlin wrote:
> 	Ignore your immediate problems for a moment and listen.

	Ok.

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

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

  switch (desktop)
  {
    case GTK:
       do_gtk_thing ();
       break;
    case QT:
    default:
         do_qt_thing ();
       break;
  }

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

	* 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
		  running' hacks.
			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,
			system-tray
			
	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
switches.

	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
values ?

	Regards,

		Michael.

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