Current desktop detection / app access - take 2.

[Havoc Pennington]

On Fri, 2004-05-28 at 04:20, Michael Meeks wrote:
> One could clearly extend that to:
> 
> 	DESKTOP=rox:gnome-vfs:gnome-button-order:gtk
> 
> 	in a way that (as far as I can see) is ~indistinguishable from
> 'DESKTOP_UI_GUIDELINES=gnome|kde'.

DESKTOP_UI_GUIDELINES would be a global toggle between entire HIG
documents, and between nothing else.

So it would preclude "kioslave" or "gnome-mime" in there, since I think
those things should be done with real specs. And it would preclude
"gnome-button-order" since I think writing an app which let users mix
half of the GNOME HIG and half of the KDE style guide would be insane.
;-)

So in fact I agree that DESKTOP=foo:bar:baz is a superset of
DESKTOP_UI_GUIDELINES - that's the point. The subset is a
better-contained and less high-impact bad hack, if we must suffer a bad
hack. It also emphasizes what the user sees rather than technology used,
so for example if Swing had a GNOME-style and KDE-style, it could choose
between them.

Now, I still think DESKTOP_UI_GUIDELINES sucks, but it's at least better
contained and defined.

> 	This is why no-one is proposing DESKTOP=foo as a solution; but
> DESKTOP=capability1:capability2:capability3 - thus splitting the problem
> into a number of O(~2) approaches.

The reason DESKTOP=foo is O(n) is because there are N desktops. The
write-a-shared-facility approach is O(1) in the number of desktops,
since each application need only code to the single shared facility.

Yes, we can expect that in practice apps will only code to 1 or 2
desktops. To me 2 is too many and seriously hurts the Linux desktop.
It's OK to have 2 desktops, it's not OK if that means apps are coded
twice.

foo:bar:baz vs. just foo is in fact worse because it creates this
combinatoric explosion of possibilities. I can't imagine testing that or
making it all work.

> 	I had expected actual engagement with the issue here. The first cut of
> the draft spec. _clearly_ mentions a plurality of desktop environments -
> which was fundamental to the (limited) amount of thought I put into it.
> cf. http://primates.ximian.com/~michael/desktop.txt.

You mention those desktops, but the nature of the solution is that it
takes an extra unit of work for *all application authors and ISVs* for
each new desktop.

I'm simply saying they won't be able to justify this work. They may do 2
desktops, *at most*, many will only do zero (Xlib, plain Qt/GTK) or 1.

Havoc