kdebase/kcontrol/kdemm (silent)

[Scott Wheeler]

On Thursday 26 August 2004 0:44, Mark Kretschmann wrote:

> What sense does it make to implement plugable backends at all when you can't 
> switch them?

I think the question is backwards -- what does it help to be able to switch 
them?  For making things configurable you have to answer "why?" not "why 
not?"

I mentioned several things that after a bit of thought that I felt were 
actually useful reasons for having it plugable, but potentially not 
configurable in the UI.

> As demonstrated by amaroK, switching backends on the fly works nicely. 

AmaroK caters to a certain culture -- the WinAMP / XMMS culture in a sense.  
And I think this is something that probably makes sense there; or at the very 
least I see that decision completely in the hands of the amaroK developers.

But I don't think that it working in amaroK means that it should be done in 
the rest of KDE.  I'm also not saying that it shouldn't be done in the 
general case, but I'm saying that I'm not yet convinced of such.

Again, users want something that works; being able to change things when it 
doesn't isn't a poor alternative (one that we may be stuck with, but I'd 
prefer to not concede that so early in our development).  If you had a 
backend that worked 100% of the time in amaroK would you still really make it 
configurable?

> Technically, this is a non-issue, and UI wise this requires just a very 
> simple selection widget with one default backend, which Matthias Kretz has 
> already implemented. 

That doesn't establish that it provides a benefit to users, which should be 
the fundamental metric of whether or not something is presented in a UI.  
Your argument above is basically still "because we can".

> To me this just screams you're disregarding the whole concept of the 
> multimedia library

Well, uhm, that depends on what you see as the "concept"; I think we just have 
different ideas on what that concept is.  I see it as something that keeps 
our options open and lets us do some experimentation.

> and aim to introduce a one-backend solution through the backdoor.

Well, yes -- I do want there to be a default and something that 3rd party 
vendors can generally count on being there.  But I've been clear on that all 
the way through this; I'd like to think that I'm pretty direct and comforable 
enough blabbing at the front door.  ;-)  I've tried to compromise and after 
some discussion even see the benefits of having a plugin based architecture 
for our simple API.  It's just that here I feel like we covered ground that I 
didn't feel like was part of that decision -- that's why I'm raising the 
issue now.

To be clear here though -- it's pretty clear that I'm in favor of GStreamer 
but let's say that we ended up deciding that NMM is just a better solution 
and it should be our default -- that wouldn't make me say "Oh, now it should 
be configurable."

So, in a sense -- yes, I would like to have a "strong" default -- even if 
that's not the one that I'd prefer.  I think that's what's best for 
application developers and users in the long run.  What that default is I 
feel like is a separate debate.

One thing that I just talked to Allan about -- and I think would probably be a 
reasonable compromise -- how about not showing this thing when there's only 
one backend installed?  The happy middle ground?

-Scott