Current Desktop capabilities - take 3.

[Shaun McCance]

On Thu, 2004-06-03 at 11:40 -0600, Michael Meeks wrote:
> So,
> 
> 	I guess that after all this active talking past each other, I suppose I
> can cut out most of the screaming style noise; and passing the comments
> through a hand-made 'constructivisation' filter I get:
> 
> 	"We like the capabilities idea, but are scared that stupid
> 	 ISVs will do bad stuff with the '<desktop>' element of that
> 	 capability list; so lets bin it".
> 
> 	This I guess mirrors the 'DESKTOP_FOO_BAA' suggestions but sticking
> with an extensible ordered list / path. The only down-side is that we'd
> need a separate DESKTOP_LAUNCH environment variable that can't bootstrap
> off this; but I guess that's fine.
> 
> 	So - a new de-launchified [ should write another spec. for
> that I suppose ] proposal is here:
> 
> 	http://primates.ximian.com/~michael/desktop.txt
> 
> 	Comments welcome, [ particulary the button descriptions - I'm
> eager not to include 'gnome' or 'kde' in that string; is 'inset' and
> 'corner' adequate ? ]

So speaking again as somebody who works for a very desktop-neutral ISV
(and again, not speaking on behalf of said ISV, my opinions are my own,
blah blah blah).

While I understand that a few projects like OO.o will take the ambitious
route of chameleonifying the interface (and I don't at all oppose such
efforts), I think most ISVs aren't going to attempt to write to multiple
toolkits, vfs layers, etc.  They'll just pick one and run with it.  It
takes quite a bit of effort to do, and I don't think the ROI is there.

It seems this proposal removes the launching stuff, considering it an
orthogonal problem, I suppose.  I think the launching stuff is probably
the most important part, and the part that most ISVs are going to be
interested in.  If my button looks a little rounder, it's not the end of
the world.  But if this program keeps opening URLs in Konqueror, and I'm
using Gnome, I'm probably going to get really annoyed really quickly.  A
solution that doesn't involve linking to any libraries (or implementing
some preferred applications system yourself in your own code) is one
that's likely to get used.

I don't have strong objections to trying to do all the other stuff.  I
just think the launching stuff is the most important, and we should
really put some effort into that.

Having said that, there are a number of fringe-case integration things
that my employer may or may not be interested in.  Off the top of my
head, I know we have issues with the proliferation of sound servers
(yeah, let's all just pick one and be done with it).  Also, the Windows
and Mac versions can launch the sound recorder to import sounds.  I'm
not sure many people use that, but I hate when the X version is missing
features.

And while I'm rambling, I may as well point out that I think the sound
recorder fits in a class of preferred applications that can't be tied to
a MIME type or URI scheme, and we should probably figure something out
to solve that issue as a whole, rather than adding yet another special
case for them.  But that's largely orthogonal to this proposal.

End Ramble.

--
Shaun