KDE4 MM, a view from usability and general applicaiton development

[Charles Samuels]

On Monday 2004 September 06 04:11 pm, Scott Wheeler wrote:
> 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.

I believe that the advantages of this framework abstraction are outweighed by 
the fact that we'll still be stuck with its problems, basically until we can 
have BIC again.  With a single API, we can make any changes we want, 
including supporting gstreamer or nmm codecs in the future (once again, the 
way xine does to arts now).

>
> 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.

Right, that's the primary reason I think basically the reason we shouldn't use 
it.  It's against the whole KDE/Qt API style.

>
> 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?

I'm not sure that's possible, as we cannot predict the future.  We also cannot 
add features to the API all the time as we need it (without BIC), and 
allowing somehow an interface into the underlying component, as I see it, 
would be an extraordinary ugly bit in the API.  And additionally each program 
would need to have to make independent interfaces for all the backends (at 
best), and at worst, only one, and then the abstraction wouldn't really be an 
abstraction, just a weak frontend that results in a lot of typecasting.

>
> 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.

Well, optimally yes, and you make a point, but again... you cannot predict the 
future.

> 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?

Right now, immediately, it does appear that Noatun is the only app in cvs.  
But I do imagine KDE getting more applications in the future, like, maybe a 
Garage Band tool like Aaron said.  Obviously I'm not saying that I'm going to 
write it, I'm saying these things may happen, and we should make the API 
correct for that situation.

>
> 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.

It's our job to make it happen.  If for KDE4 we can't get nmm or gstreamer or 
whatever to commit to an API, then I suppose we don't have a choice.  But 
again, it appears that both gstreamer and nmm would be doing that if we 
asked.

-Charles

-- 
Charles Samuels <charles at kde.org>
 Don't changes horses in the middle of an apocalypse!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20040906/cd5e4d06/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia