summary of the aKademy meetings

[Charles Samuels]

On Monday 2004 September 06 07:12 am, Matthias Kretz wrote:
> On Monday 06 September 2004 11:43, Charles Samuels wrote:
> > On Monday 2004 September 06 02:13 am, Allan Sandfeld Jensen wrote:
> > > Right now you can see kdemm as a showcase of different options, we
> > > would like people to try it out, break it, come up with
> > > experience-based recommendations for a default framework for KDE 4,
> > > rather than the guesswork, drinking games and numerology we would have
> > > used to pick on at aKademy.
> >
> > Wait, wait, wait, this is just for KDE 3.4?
>
> If for KDE 3.4 than only to give a really good test-drive. IMHO, only
> shipping it as an add-on won't be as good since then we can't ship the
> ported knotify, konq-sound and so on
>
> > My objections have all been shattered.  While at the same time I find it
> > quite stupid to introduce *yet another* API just for 3.4. So under those
> > conditions, I again don't see the point.
> >
> > So, to summarize:
> >
> > Advantages:
> >  - A single API (like with KAudioPlayer which itself could be abstracted
> > to do this anyway)
> >
> > Disadvantages:
> >  - We'll get lazy and stick with this stuff for 4.0.
>
> I'd say KDE 4 isn't ready if kdemm isn't ready. And I'm committed to
> getting it done right.

Yes, and if you really wanted to get it done right, I doubt you'd be making an 
abstraction, you just don't want to have to commit to framework.

>
> >  - Another API
>
> In addition to what? I mean the current KDE media interfaces are all either
> direct wrappers for aRts classes or you have to use KMediaPlayer, which is
> often overkill (most apps wanting to play a media file don't want a KPart
> for that).

In addition to the backend, in addition to KAudioPlayer, in addition to aRts, 
and in addition to whatever backend we'll be switching to.  (This is as of 
KDE3.4, not KDE4).

KDE4 of course will only have APIs, KDEMM and whatever backends are used -- 
which is still plenty as KDEMM won't let me deal with the backend.

>
> >  - More stuff in kdelibs, one that's very weak
>
> More compared to what? After all we'll throw out artskde (and probably move
> it to kdemultimedia to the aRts backend). And what is weak? The API?

Yes, you can't do anything with it except apparently play and set the volume. 
I don't see how at least noatun will be able to use this API at all.

>
> >  - Still won't make us actually audiosystem agnostic
>
> agnostic?
> dict:agnostic only tells me a meaning for the word I've already known, but
> I don't see what that's supposed to mean in this context...

KDE will still be dependant on one of the backend frameworks, as our 
applications start using those frameworks directly.

>
> >  - API changing once now for 3.4, and again 4.0
>
> What API _changes_?

Scroll up and read my reply starting with "In addition to the backend"

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