From kde-multimedia Mon Sep 06 10:56:40 2004 From: Charles Samuels Date: Mon, 06 Sep 2004 10:56:40 +0000 To: kde-multimedia Subject: Re: summary of the aKademy meetings Message-Id: <200409060356.43105.charles () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109446821518864 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1002793809==" --===============1002793809== Content-Type: multipart/signed; boundary="nextPart2340193.ClsnrpcDbo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2340193.ClsnrpcDbo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 man= y=20 soundsystems as there are applications (and this is just what's going to=20 happen. Anyway, KAudioPlayer already works, and it does it without an abstraction. = If=20 you want a KDE frontend to The KDE Multimedia System, then make just bindin= gs=20 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= =20 don't have our own wrapper Qt, that's because we agreed that Qt will be our= =20 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 w= ant=20 a f%@#ing good API for a change. If aRts were any good, we'd be using that= =20 exclusively quite happily. Qt wasn't perfect when we first started using i= t,=20 but it did get better, and KDE got better with it because we as a project=20 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 sin= ce > 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=20 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 framew= ork=20 for it at all, they'll be using arts directly. This has nothing at all to = do=20 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=20 in the position to Potentially Set These Policies for Linux. We ARE the=20 desktop! 2) So what? it's not like these frameworks both can't be used on a single=20 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=20 multimedia. At least until they learn to live with it. Successful project= s=20 do not make decisions are religious zealotry, successful projects make=20 decisions based on the quality of the product. (Unless said projects are ma= de=20 by companies, in which case they choose whatever products come from Microso= ft=20 "just cuz" :) > - KDE can fit better into different requirements/environments: > Users/Admins might want to use some special features of that one multimed= ia > 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 o= f=20 us partially like. =2DCharles =2D-=20 Charles Samuels Don't changes horses in the middle of an apocalypse! --nextPart2340193.ClsnrpcDbo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBPEJrWS4Pv66UcxkRAlAVAJ9s7y8kWEeZWjQjZ1vciM4pXPShLgCfSTYn lPR0Vfw6takvLVQOVIlOL9U= =asse -----END PGP SIGNATURE----- --nextPart2340193.ClsnrpcDbo-- --===============1002793809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia --===============1002793809==--