summary of the aKademy meetings

[Charles Samuels]

On Monday 2004 September 06 02:33 pm, Alexander Neundorf wrote:
> On Monday 06 September 2004 23:08, Charles Samuels wrote:
> > On Monday 2004 September 06 09:30 am, Michael Pyne wrote:
> > > Well, if we pick an API, app writers will have to do one of two things:
> > >
> > > 1) Use the backend API directly, or
> > > 2) Use a KDE-provided wrapper for simplicity.
> > >
> > > If we do number 2), then making it 'pluggable' is almost free, so I'll
> > > assume you'd rather have option 1). ;)
> >
> > No, it's not, if you want all the features of the backend API, then you
> > have to drop down to that backend API. The stuff in make-it-cool doesn't
> > let you insert filters, or change its output mode... or anything. The
>
> As far as I understood, it is intended to be a simple API for simple
> purposes. For advanced stuff use the backend API directly.

Exactly, we're on the same page here.  I just need to state my qualms with 
this system.

Suppose you are JuK, and suddenly you want to support a feature that the 
generic framework doesn't support.  Well, you're SOL, all the MM stuff in JuK 
will have to be rewritten to use GStreamer or NMM directly.  That sucks.  
Please, admit it, that does suck.

What's also silly is that the frameworks themselves are just frontends to the 
codecs and the filters.  Then you have this generic framework that is an 
abstraction between the different abstractions.

>
> > <read me>
> > What applications want is something to play audio/video with.  What
> > applications want is a kpart to do it.  They don't care how the kpart
> > does it.  This way we don't have a weak API in cvs and call it "the KDE
> > MM Framework."
> > </read me>
>
> Why would I want to have a kpart ? I have a perfectly working widget here
> which can play videos for me. Wrapping this widget in a kpart so that it
> can be embedded in konqy is trivial.

First, I don't exactly understand what you mean here.

I'm not necessarily condoning the idea of a KPart, but for a "Easy" API, don't 
give its users the impression that it's a multimedia API.  It's an API that's 
nothing more for playing a sound very very easily, and if you feel there's 
even the slightest possiblity that you'll want more than that, then there 
should be huge <blink> tags in the documentation saying to avoid it.  It is 
not a framework, it shouldn't be seen as anything more than something that 
you might use in the following instances:

 - Previewing in Konq (or, say, a P2P application)
 - thumbnails in Konq 
 - sound effects in very simple games (KBattleship-yes, games like Boson-no)

Programs like JuK and Noatun, should definitely be out of the question.

thanks

-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/0cbdd390/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia