KDE4 MM, a view from usability and general applicaiton development

[Scott Wheeler]

On Tuesday 07 September 2004 0:53, Charles Samuels wrote:
> On Monday 2004 September 06 03:51 pm, Scott Wheeler wrote:
> > Which is different how, exactly?
> 
> Please read the very last email I sent.

Which last mail, exactly?  ;-)

Anyway -- I'll jump to what I think you're getting at.

Let's be honest -- binding ourselves to a single API has some benefits.  Not 
binding ourselves to a single API (in the simple case) also has some 
benefits.  Recognizing that as a starting point I see as our only real means 
of progressing from the current impass.

The only real downside I see to the combination of a "strongly recommended 
API" plus "a plugable architecture" is that it's probably hard to build 
something on the simple API and extend it.

I've been working with the assumption that application developers would know 
what they needed generally speaking and that those that need the additional 
stuff wouldn't use the simple API.  You seem to disagree here.  I'm not sure 
that we can't work out something in the present API to compromise on this 
issue.  What do you specifically see as missing?

Also in terms of usage cases I personally don't intend to add anything not in 
the simple API to JuK.  Most JuK users appreciate its simplicity.  I'm all 
for dropping the configurable backends once we've got something that I can 
use that doesn't suck as much as aRts.  For my needs the API in kdelibs is 
plenty.

I don't see other applications in KDE CVS that are corner cases.  Noatun will 
clearly need more than the simple API.  Third party apps may as well.  What 
else?

On the other hand keeping things abstract (and plugable) provides more sane 
ways to manage a BC API.  Very, very few applications in KDE need more than 
that.  It's a way to set up an interface that we can reliably promise not to 
break probably even into the KDE 5 series.  There's nothing else that makes 
that possible presently.

-Scott