From kde-multimedia Mon Sep 06 14:36:52 2004 From: Scott Wheeler Date: Mon, 06 Sep 2004 14:36:52 +0000 To: kde-multimedia Subject: Re: summary of the aKademy meetings Message-Id: <200409061636.52380.wheeler () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109448142521997 On Monday 06 September 2004 12:56, Charles Samuels wrote: > 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. Again, you're very much overstating the scope of this problem. Noatun is the only application in CVS that (a) doesn't have its own abstraction layer or (b) won't be using the generic framework. Certainly we all tend to look at the issue as it relates to problems in our own applications, but we have to *try* to see beyond that... While that is of course an issue that merits some though it's not like there are dozens of applications around that will be affected by this. > 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. Every single MM developer at the conference agreed that we need a simple abstraction for playing stuff. There were a number of points that we didn't always agree on (or even how that would be done), but *everyone* agreed that saying "just use the backend API" was a bad idea. I don't think you're going to get far pushing on that one. > 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. No, they want to be able to do stuff; in the overwhelming majority of cases "stuff" is covered in the API that's currently in make_it_cool. If you think game developers care one little bit about the quality of the backend API, well, you're being short-sighted. "How do I play stuff? Can I put it in a widget?" are their questions. There's a small group of us in the KDE community -- maybe about 5 -- that come into contact with the lower level APIs. We're all reading this. Most of us were at aKademy. We're the ones that have to make these choices; not some ethereal set of developers that, well, just don't exist. > > 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. Heh. I think both frameworks would love to be at the point that they could declare the API stable right now; but they're not. They might be by KDE 4 -- I know some of the GStreamer devels are targeting that specifically, but that doesn't mean that we should throw out the backup plan. ;-) Even if we only shipped one plugin I would still at this point go along with the plugable stuff. That's our insurance policy. To put things in other terms -- what we'll actually ship or recommend or make configurable in the UI I still think is open; however, I see this as a separate question from the more basic ability to have it plugable for other reasons. > > - 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. Well, while I don't think this point is all that interesting, I think what Matthias was trying to say was that if someone had some older applications using aRts (hence they have an arts daemon running) that they would tell new apps to use that daemon too. > > - 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! Yeah, that's why everyone switched over to aRts right? ;-) -Scott _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia