From kde-multimedia Tue Sep 07 10:05:46 2004 From: Matthias Kretz Date: Tue, 07 Sep 2004 10:05:46 +0000 To: kde-multimedia Subject: Re: KDE4 MM, Message-Id: <200409071205.47053.kretz () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109455164010847 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1673994449==" --===============1673994449== Content-Type: multipart/signed; boundary="nextPart1357465.XpOo4ZClYF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1357465.XpOo4ZClYF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 September 2004 01:40, Charles Samuels wrote: > I believe that the advantages of this framework abstraction are outweighed > by the fact that we'll still be stuck with its problems, basically until = we > can have BIC again. With a single API, we can make any changes we want, > including supporting gstreamer or nmm codecs in the future (once again, t= he > way xine does to arts now). With "a single API" you mean using e.g. only the API provided by NMM and=20 nothing on top of it? > Right, that's the primary reason I think basically the reason we shouldn't > use it. It's against the whole KDE/Qt API style. What is against the "style"? That our kdemm API is not complete? > > I've been working with the assumption that application developers would > > know what they needed generally speaking and that those that need the > > additional stuff wouldn't use the simple API. You seem to disagree her= e. > > I'm not sure that we can't work out something in the present API to > > compromise on this issue. What do you specifically see as missing? > > I'm not sure that's possible, as we cannot predict the future. We also > cannot add features to the API all the time as we need it (without BIC), > and allowing somehow an interface into the underlying component, as I see > it, would be an extraordinary ugly bit in the API. And additionally each > program would need to have to make independent interfaces for all the > backends (at best), and at worst, only one, and then the abstraction > wouldn't really be an abstraction, just a weak frontend that results in a > lot of typecasting. I'm not sure we have the same objective for a KDE MM API. What should a KDE= MM=20 API do in your opinion (I still have not understood if you want to have a K= DE=20 API for MM or not)? > > For my needs the API=20 > > in kdelibs is plenty. > > Well, optimally yes, and you make a point, but again... you cannot predict > the future. Why would he need to? He wants to have simple mm playback now, no more. So = for=20 now the kdemm API is enough. This decision doesn't stop him from using=20 something else later. > Right now, immediately, it does appear that Noatun is the only app in cvs. > But I do imagine KDE getting more applications in the future, like, maybe= a > Garage Band tool like Aaron said. Obviously I'm not saying that I'm going > to write it, I'm saying these things may happen, and we should make the A= PI > correct for that situation. So now you want to have a KDE API that does it all? Sorry, but I have not been able to see what you want to have for KDE 4. A l= ot=20 of my arguments with you had been guesswork at what you want and what you=20 don't want (or rather think is good or isn't). I really don't want to force= =20 my ideas on KDE, I want to have the best MM solution for KDE 4 that we can= =20 get/create. And I believe you have something to say there as well, I'm just= =20 unable to understand what you think we should do. =2D-=20 C'ya Matthias ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homeip.net/ MatthiasKretz@gmx.net, kretz@kde.org, Matthias.Kretz@urz.uni-heidelberg.de --nextPart1357465.XpOo4ZClYF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBPYf6yg4WnCj6OIoRAtwIAJ9d0AKVOq0CPZrk7jTyq3d9cN1XSQCdGaHn GsBo+7zdNH/fjeImqWstmeg= =yGyJ -----END PGP SIGNATURE----- --nextPart1357465.XpOo4ZClYF-- --===============1673994449== 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 --===============1673994449==--