Current desktop detection / app access - take 2.

[Michael Meeks]

Hi Havoc,

On Mon, 2004-05-17 at 23:15 -0400, Havoc Pennington wrote:
> Hmm, I ended up writing a bit of a rant here, please just take it
> as my initial opinion.

	:-) fair enough; I'm in no incredible hurry - this is a blue-sky:

	"wouldn't it be nice to remove those patches that integrate
	 with only KDE _or_ Gnome from OO.o in favour of something
	 that works well"

	Of course - we could do all the wrapper / launch script goodness inside
OO.o - but even so, there's no reliable / good way to detect what
desktop you're using, so - one just gets lumbered with this mess with no
way to fix it :-)

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

	Or is a better way to fix the same problem in a complimentary way ?

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

	Um; well - presumably the mime settings for whatever DESKTOP is
pointing at 'just work' - of course, if they are (eventually) the same
for KDE/GNOME/<whatever> - then brilliant, however in the meantime until
that chunk of code / codification is complete you get whatever
association you configured for that desktop for PDF.

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

	Quite likely; but the problem is rather different: you still need an
API to do the launch - one popular one in Gnome is:
'fork gnome-open' which is what this is essentially a wrapper for in a
desktop-neutral way.

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

	Sure - this is an ideal solution, but it's not going to arrive anytime
soon (AFAICS); whereas the 'DESKTOP=' solution can be back-ported to KDE
3.2.x and Gnome 2.6.x and 'just work' really fast - and in no way
precludes doing it 'right' at a later date.

> Which leads to a philosophical objection, to me apps and the desktop
> environment should be orthogonal so users can choose the best apps.

	Of course - but the actual selection method per desktop is a rather
orthogonal problem; ultimately though - people are going to want to
choose a stock KDE or stock Gnome distro - _particularly_ the up-stream
projects; and if we want a shared specification we're going to have to
design that in to get it adopted - even if then every distributor goes
and turns it off ;-> [ but I digress ].

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

	Whatever; was there something annoying in the text that needed fixing;
was it ultimately s/integrated/optimized/ ?

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

	Well - I guess, for systems where you have some change of gauging the
features it makes sense - however for the desktop, it's simply not
possible currently. The string list is in effect a 'capability' list for
basic desktop services. There should be no problem with:
"kde3:kde22:kde11" or whatever in the list.

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

	I'm not adverse to that; all I really want to use is the 'launch'
application, and the 'qt/kde' integration thing.

> A random small problem with DESKTOP is that if users set it in their
> .bashrc, you can never add new stuff to it

	Sure; setting from .bashrc is not intended; setting from
'gnome-session' is where I had anticipated this happening - indeed
although the hacker can override it for testing, one would hope that it
would not be user-manipulated [ especially since it's advisory rather
than mandatory - most people won't care ].

> 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 ;-)

	Certainly good/best even but often best == slow, and labour intensive.

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

	Well - there are better ways - but ultimately there are two things I'm
looking for:

	a) toolkit usage:
		I don't think anyone seriously believes we're going
		to have 1 toolkit anytime soon.
	b) launching URI viewers / helpers:
		you're going to need to fork something to handle a
		URL out of process - so, do we need a shared, shared
		library to do that ? or can we just use a launch
		script.

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

	Well - empirically this isn't what's happened with OO.o - we now have
two native toolkit integration backends, and yes this creates more
maintenance, but it also gives nice integration.

	The "don't do anything becuase it can't be perfect" thing is just
nonsense :-) lets face it, nothing is perfect; it's just different. And
OO.o is a _typical_ ISV-style non-free-software application; it is
_incredibly_ circumspect about the system; and dlopen's many libraries
that people link to, has several glibc ABI breakage bugs that it works
around etc. etc. writing 2 NWF pieces is a smallish thing; and we'll
~never have a single toolkit so ...

> Nitpicks on the X property:

	These all sound great; I've no idea what we should say - but how does
_NET_DESKTOP, set on just screen 0, set by whomever gets there first.

> > 	DESKTOP="kde:kio:gnome-vfs:qt"
> 
> Can you imagine the QA matrix :-P

	;-) sure, but lets remember that mostly the pieces are rather
orthogonal, and _most_ apps will stick to integrating with KDE or Gnome
rather than both.

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

	Sure; or we could use desktop-launch now, and make it irrelevant in
future :-) (and/or replace it with a binary that does the right thing).

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

	Toolkit detection. Ultimately it's pretty impossible to detect what
desktop you are running or what toolkit the user wants to be used for
integration; clearly we could have a setting: ~/.desktop-toolkit - but
well; that's just a different style of DESKTOP env. var.

	The current code does something like:

http://ooo.ximian.com/lxr/source/gsl/vcl/unx/source/gdi/dtint.cxx?v=mws_srx645#142

	And this is before we try to do (earlier) toolkit detection; it boils
down to:

	if WM is Kwin -> KDE
	else if GNOME_SM_PROXY || NAUTILUS_DESKTOP_WINDOW_ID \
		registered -> Gnome
	else -> Plain X

> It's only easier *for us* and *in the very short term*

	Well - it's easy for me maintaining the patches; it's easier for the
up-stream ISV that is OO.o, and it's useful ~long-term since we'll not
have a single toolkit to integrate with in the next 5 years ;->

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

	Sure - I agree this quick hack would remove some of the impetus behind
solving the more abstract MIME problem; but I don't (personally) see
that as a really good reason not to do it. :-)

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

	:-) thanks,

	I don't know how to post it, and I'm not in a particular hurry,

	Regards,

		Michael.

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