Current desktop detection / app access - take 2.
Dave Cridland [Home]
dave at cridland.net
Thu May 27 22:29:33 EEST 2004
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
> 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
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
> effort, and so I don't see how it's better even by the "less work
> faster" metric if we really, genuinely intend to solve the
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:
> 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
> 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?
More information about the xdg