From kde-multimedia  Mon Sep 06 23:51:51 2004
From: Allan Sandfeld Jensen <kde () carewolf ! com>
Date: Mon, 06 Sep 2004 23:51:51 +0000
To: kde-multimedia
Subject: Re: summary of the aKademy meetings
Message-Id: <200409070151.51296.kde () carewolf ! com>
X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109451461430870

On Tuesday 07 September 2004 00:49, Charles Samuels wrote:
>
> 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.
>
That's not the idea. KDEMM is (surprise!) writen in an objection oriented 
language, and as such is very suitable for extensions. The kdemm-backends are 
free to provide additional features not required by the basic API, 
applications can use these additional features if they test for them first. 

> 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.
>
Actually the goal of working with JuK is already reached, the current goal 
will be able to deal with the multimedia needs of all the applications 
currently in KDE-main. Amarok was said from the beginning to not be a goal. I 
also see nothing in boson which we wouldn't able to deal with.

`Allan
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia