Current desktop detection / app access - take 2.

[Dave Cridland [Home]]

On Thu May 27 19:50:51 2004, Havoc Pennington wrote:
> Plus there's the
> trivial get-it-done-today interim spec Waldo posted, "there is a 
> binary
> desktop-launch, use that to launch" - spec completed. We're done, I
> don't want to hear more about how long it will take to write the 
> spec.
> ;-)
> 
> 
For one portion. Moreover, desktop-launch doesn't do enough for some 
cases, I believe - I can't pass in a data stream, I can't specify the 
content type myself, etc. Hence I have to hope the desktop deployed 
is using extensions I know about.

It's certainly better than nothing, mind.

> For tooltips, button order, etc. I think we should address that in 
> a way
> specific to the problem at hand. DESKTOP_UI_GUIDELINES=gnome|kde for
> example, is much less bad than DESKTOP=gnome which is a hack of
> unbounded damage. Though choosing one set of guidelines to me is the
> only sane thing to do, I agree it is not politically feasible (yet).
> 
> 
I'd have thought that the '_UI_GUIDELINES' portion would get ignored 
for all purposes. Perhaps I have less faith than you, but I suspect 
people would be referring to it without '_UI_GUIDELINES' on the end 
of the name within a month.


> To me it's obvious that if we're really going to support multiple
> desktops in the long term, we have to do so sanely and 
> maintainably. If
> the goal is to give lip service for a while and then drop one of the
> desktops, then DESKTOP=foo sounds like a great way to avoid wasting
> time. But DESKTOP=foo is an O(n) rather than O(1) approach in terms 
> of
> effort, and so I don't see how it's better even by the "less work 
> and
> faster" metric if we really, genuinely intend to solve the 
> multi-desktop
> issues.
> 
> 
I agree - to a point, I think. What we need is a 'write the app to do 
X, and write one X per desktop' - I think that's what you're saying, 
and I agree.

But we need a short-term solution - I think the traffic on the list 
supports that - although I entirely sympathise with the viewpoint 
that a bad solution now will cost us hugely later.


> If we're going down the DESKTOP=foo road what we're saying is: 
> "There
> are two Linux desktop platforms. You have to port your app twice and
> separately test and certify with each platform. We have no plans to 
> fix
> this problem, in fact for the apps we write ourselves we are porting
> twice and spending double the effort."
> 
> 
I agree, but I don't think tacking _UI_GUIDELINES onto an environment 
variable stands a snowball's chance of stopping that mentality. It's 
saying all the above, plus, 'But we like to pretend we have a better 
way coming, please pretend this too.'

So what's the chance of getting a fantastically simple API together, 
plus a shared library that implements it? Initially, it might well 
pass the inner workings through to desktop-launch, for instance. But 
it could also handle it by loading in a shared library specific to 
the required desktop, later on.

And later, still, when the 'proper' standards come about, the library 
could simply directly implement that.

I don't think we're talking about a major piece of work here for any 
desktop or ourselves.

Personally, in any case, my personal wish for desktop 
interoperability would be that wxWidgets wrapped them both, so a user 
could essentially pick what desktop to compile and run a GUI app for, 
Windows and Mac included. But that's idealism, and we need 
pragmaticism for today, I think.

So, quick straw poll:

Am I asking for a bit much - a deliberately lightweight, restricted, 
integration system to tide us over, but one that for smaller apps 
might well become the norm?

What would it need?

Can we manage an API that's in, say, plain C?

Am I barking mad?

Dave.