summary of the aKademy meetings

[Charles Samuels]

On Monday 2004 September 06 03:00 am, Scott Wheeler wrote:
> The idea is that this *is* for KDE 4 though; this is just the first
> iteration of the API, which we naturally expect to refactor in the next
> year.

You cannot refactor a (ahem) stupid idea into a good API. Don't make as many 
soundsystems as there are applications (and this is just what's going to 
happen.

Anyway, KAudioPlayer already works, and it does it without an abstraction.  If 
you want a KDE frontend to The KDE Multimedia System, then make just bindings 
to whatever becomes the KDE MM System.

and now:

On Monday 2004 September 06 01:14 am, Matthias Kretz wrote:
> What exactly is bloated about it? The fact that you interface and
> implementation are separate, and therefor every call to a method has to go
> through the virtual table?
> Or do you mean the backend loading that happens at construction of the
> Factory?

I mean the fact that we have a wrapper around what actually is the API. We 
don't have our own wrapper Qt, that's because we agreed that Qt will be our 
API.  So let's agree that NMM, GStreamer or whatever is our API.

> But I don't want to force that non-Qt/KDE API on KDE developers. They
> should be able to choose what they want.
No, they shouldn't just as they can't choose between Qt, GTK and Motif. I want 
a f%@#ing good API for a change. If aRts were any good, we'd be using that 
exclusively quite happily.  Qt wasn't perfect when we first started using it, 
but it did get better, and KDE got better with it because we as a project 
stuck to the toolkit and helped improve it ourself.

> Just to get an overview what the multiple backends give us:
> - Independent from the API/ABI stability of the multimedia Frameworks since
> for an incompatible version you can just add a new backend - no code using
> kdemm broken.
So we fix that by making sure the framework we use is stable by talking to its 
developers.

> - Compatible to KDE 2 and 3: When KDE 4 comes out some people still might
> be using aRts apps and therefor might require the aRts backend to be used.
That really doesn't make any sense at all.  They won't be using this framework 
for it at all, they'll be using arts directly.  This has nothing at all to do 
with it.

> - Independent from the success of the multimedia Framework we chose. If we
> decide to go for gstreamer only and then MAS becomes the preferred
> multimedia system for Linux we're stuck with gstreamer - just like we have
> it now with aRts.

1) Then we switch for our next major release.  Also, do not forget that KDE is 
in the position to Potentially Set These Policies for Linux. We ARE the 
desktop!

2) So what? it's not like these frameworks both can't be used on a single 
machine.

> - I'd guess if we have to decide on the one and only framework now we'd
> take gst, but then you have those anti-glib fanatics ;-) flaming again
> because of a hard dependence of KDE against glib. (pretty much a moot
> point)

If they don't like glib, or they don't like nmm, they don't have to use KDE's 
multimedia.  At least until they learn to live with it.  Successful projects 
do not make decisions are religious zealotry, successful projects make 
decisions based on the quality of the product. (Unless said projects are made 
by companies, in which case they choose whatever products come from Microsoft 
"just cuz" :)

> - KDE can fit better into different requirements/environments:
> Users/Admins might want to use some special features of that one multimedia
> framework that isn't possible with another framework (yet). I'd like to
> give them the freedom to chose that framework then.
Users do not use frameworks. Admins do not use frameworks.
Users use applications.
Admins configure applications.
Developers (us) use frameworks.

>
> about fragmentation in the multimedia apps:
> It probably cannot get worse than what we have now with apps using
> mplayer/xine/gstreamer/aRts. And it probably wouldn't if we choose one
> backend since the will always be apps using something different than the
> KDE core.

Well, the important part here is to choose a framework that at least some of 
us partially like.

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