Current desktop detection / app access - take 2.

[Havoc Pennington]

Hi,

Hmm, I ended up writing a bit of a rant here, please just take it as my
initial opinion.

We should get Jonathan Blandford to comment on this, he's offline for a
few days though. He's been paying attention to the
MIME/preferred-applications stuff, which I'm guessing conflicts with the
desktop-launch concept. (If I change my preferred application or MIME
setting for PDF files to foobar, then do I get foobar or the PDF viewer
that's part of the desktop, for example. And if there's a standard
preferred applications system, shouldn't it just allow per-desktop
settings, instead of having this separate desktop-launch thing?)

I guess I'll be blunt and say this DESKTOP thing seems like a pretty
huge hack, I'd rather see us just standardize the MIME and
preferred-apps systems, with per-desktop configuration included in those
specs if required.

Perhaps we should explicitly use the OnlyShowIn field in .desktop files
to solve this problem. For example, if the MIME handlers for PDF are
kpdf, gpdf, xpdf then if kpdf/gpdf are OnlyShowIn they would only be
used in respective desktop, and xpdf would be used otherwise. Perhaps a
bad example since I don't personally think *pdf should be OnlyShowIn or
tied to the desktop...

Which leads to a philosophical objection, to me apps and the desktop
environment should be orthogonal so users can choose the best apps. In
fact it's hard for me to think of a document-focused app that should be
"part of the desktop"/OnlyShowIn (text editor, word processor, pdf
viewer, etc) though it makes sense to me if small "utilities"
(calculator, terminal) are part of the desktop.

I'm not saying desktop projects shouldn't write integrated apps - I'm
all for that - but I don't think these apps are part of the desktop
shell/environment, rather they are part of the desktop project and
optimized for the shell/environment. Nitpicking perhaps, but I think
important.

A second philosophical objection I have here is the difference between
imake and autoconf, i.e. platform tests vs. feature tests. If you end up
with a bunch of "if (gnome) then blah" kind of crap, then it makes
future interoperability hard to add, and makes it harder to adapt to
multiple versions of GNOME. The ability to put "gnome-vfs" in the
colon-separated list sort of helps, but I'd go further and disallow
having the name of the overall desktop in said list, only allow feature
tests.

A random small problem with DESKTOP is that if users set it in their
.bashrc, you can never add new stuff to it - for example say the default
in Linux Distribution v1 is DESKTOP=kde:kioslave:qt, and in v2 you
change the default to DESKTOP=kde:kioslave:qt:foobar, then users who
upgrade will not get the "foobar" part or any reorderings. One way to
solve this is a series of env variables such as KIOSLAVE_REQUESTED=1, 
perhaps. Not super appealing either of course.

Inline comments follow...

On Mon, 2004-05-17 at 11:31, Michael Meeks wrote:
> 	When applications wish to integrate well with different
> desktop technologies, one approach is standardisation of every ISV
> interface;

One _good_ approach ;-) with note that we can instead agree on the
"backends" of the ISV interfaces, e.g. we can have a common MIME system
spec with Qt and GTK specific APIs, or pursue the proposal discussed a
while back to allow common vfs/ioslave backends, or whatever. There are
lots of better ways than writing every app ten times to handle the
various desktops.

>  another is to allow an application to detect, and integrate
> with several types of interface.

One _bad_ approach ;-)

This is just insanely unmaintainable IMO. It doesn't even work right,
unless all the apps support all the ISV interfaces. Say for example some
apps support choice of kioslave or gnome-vfs, and some only support one
or the other, and some neither; the result for the user is a ridiculous
unpredictable nightmare. I'm also having trouble imagining any
application authors actually doing this. If I were maintaining an app, I
sure as heck would not do it. I'd either pick one API set, or I'd stick
to only least-common-denominator.

> 	a) the 'DESKTOP' environment variable - this should be the
> 	   primary source of desktop information or
> 	b) the 'DESKTOP' root window X property if it is not set.

Nitpicks on the X property:
 - should be _NET_DESKTOP
 - need to specify multihead behavior (set only on screen 0, must be 
   the same on all screens, or whatever)
 - two apps could set the property, unless you require the owner of 
   a manager selection to set it, or otherwise promise uniqueness
   (for example sometimes gnome-settings-daemon/kded fire up 
    when running the other desktop)

> 	In many cases, we would expect to see eg. DESKTOP="kde:kio:qt"
> or perhaps DESKTOP="gnome:gnome-vfs:gtk", however more complex
> scenarios should be tolerated; for example - if a user was concerned
> that a more powerful file access layer was used if available, but
> preferring kio to gnome-vfs they might specify:
> 
> 	DESKTOP="kde:kio:gnome-vfs:qt"

Can you imagine the QA matrix :-P

> 	In order to allow an application to use the most appropriate
> helper application to launch a viewer for a given URI, it is proposed
> that we have a small script that bootstraps from this DESKTOP setting.
> This script shall be in the system path, called 'desktop-launch' it's
> essential algorithm should be that of:

Seems to me that if we unify the MIME system, gnome-open and the KDE
equivalent automatically do exactly the same thing (and a desktop-launch
could be implemented that replaced both).

What are the uses for DESKTOP other than the MIME handler stuff?

I think the appeal of a hack like this is probably that it seems easier,
however my prediction is that it's harder overall, once you consider the
QA nightmare and nasty impact on application authors. It's only easier
*for us* and *in the very short term*

I think we have pretty solid technically sound approaches in mind for
the major interoperability areas, and it really is not that hard to do
the work correctly if more people start working on it. In particular the
MIME stuff should be easy to complete in the near future, and that seems
to be the focus of this proposal.

Don't misunderstand my post, if consensus disagrees with me then so be
it, and of course you're welcome to post the spec immediately on
freedesktop.org under proposed specs. Just putting in my .02.

Havoc