What about the various BSD’s?

And why are you still comparing Phonon to Gstreamer, when they are in no shape or form alternatives to each other? But to answer your question: Phonon runs on all platform that Qt supports. It might not work on platforms that Qt is not ported to, but since Phonon is used with Qt, that’s totally irrelevant.

If KDE/Qt used Gstreamer instead, they would have to make sure that the platform the software is running on has Gstreamer installed. If not, it would not work. With Phonon, they would not have to worry about that, since Phonon would work with what’s already present on the system.

the more I read these comments, the more obvious ot becomes that Gstreamer-folks totally misunderstood what was being said, and then proceeded to complain and whine. It would be nice for them to admit that they are totally, 100% wrong on this issue, but I’m not holding my breath.

This whole thing seems to be about Gstreamer-folks insisting that everyone should use their software, and nothing but their software. And if someone uses something else, or uses Gstreamer indirectly (like, through Phonon), they start to whine.

There is a misunderstanding regarding the reference to aRts.

While aRts has been used as KDE3’s audio framework, the reference in the context of Phonon, i.e. not wanting to repeat the aRts mistake, means not to repeat the mistake of tying our API to one specific implementation.

Remember that at the time of the decision GStreamer hadn’t API or ABI stability commitment yet, at least not for the expected lifespan of KDE4.

So since there was a need for an API which can accomodate different incompatible versions of GStreamer, adding the capability to accomodate different frameworks was basically a logical next step.

1. I agree
2. a) aRts and Esound are not at all comparable with gstreamer or even Phonon. Different layer altogether. As for gstreamer shaping up to be another trainwreck – I think a lot of people would disagree, and it would be a shame because it’s the best we got.
2. b) Last I checked, gstreamer did work on win32 and MacOS X (and Solaris, etc) didn’t it? How is Phonon more “cross-platform” than gstreamer?
2. c) sounds like NIH to me, but OK, fine, matter of taste I guess. A thinner layer probably could have done the trick.

1. It is not a multimedia stack Christian, so relax. It doesn’t compete with GStreamer.

2. Abstracting audio and multimedia away for Qt and KDE applications is entirely sensible, and is probably what other non-Qt applications should do as well:

a) The Linux and open source multimedia landscape is littered with train wrecks, and GStreamer is shaping up to be another one. Tying all KDE applications to it is not a fantastic idea, and I don’t believe it is what Gnome should be doing either. KDE went through the whole Arts thing, and then Gnome went through their whole esound fiasco as well as they painted right over Arts. So what?

b) Phonon can be used by Qt and KDE applications on different platforms and use the frameworks on those respective platforms. GStreamer is not cross-platform.

c) Accessing multimedia functionality for Qt applications can be done through some nice looking and universally usable Qt classes that act like any others. A KDE or Qt application developer does not have to know about GStreamer’s API or the API of any other multimedia framework. They just need to know about Qt and they can do multimedia.

Sorry Christian, but unless GStreamer becomes a saner and more stable multimedia platform then you merely prove the case for Phonon. KDE and Qt applications will be insulated from the insanity and get something that is actually usable to program.

“First of all is the problem that you have three major sources for bugs instead of one.”

Yer. The bugs are identified and handled within Qt and Phonon and worked around there. You’re still going to have exactly the same trouble getting GStreamer running itself on different platforms, and then getting application developers to use that.

“Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either.”

Yes I know Christian. wxWidgets was awful to program for, repeated an awful lot of cross-platform GUI mistakes and just wasn’t very good, quite frankly. There is another cross-platform toolkit in the world that has managed to do a pretty good and much better cross-platform job than anything else – Qt.

no I am not someone who calls himself a developer and I don’t think that I am more clever than the rest of you either. Still I want to make some comments on this discusssion, but not in order to make the heat in it grow ever further…

I am using Windows at work and home, I have been using different kinds of DOS, MacOS, OS/2, HP-UX, SunOS, OpenSolaris, Linux, BeOS and others. I have tried Gnome, KDE, Xfce, CDE and others. I like to try new things and I like to have choices, though I like to have standards, too, in order to have a choice.

Why this long introduction? Cause I want to make clear that I am not a “fanboy” of anything, who can just see the view of “his” side.

What is the point of the whole discussion, I wonder? Discussions are good, and can be productive and lead to new insights. People should discuss things. But what I see here, is so often so emotional, that it is not productive anymore.

Well, there has been made a decision to use Phonon in KDE4 as an abstraction layer. Has that been a stupid decision? One have arguments for that is has been, others have arguments for that it hasn’t been. Only time will tell.

But, the people who made that decision have given reasons for why they made that decision and with what intention, namely (and please correct me, if I am wrong) in order to simplify the “simple use of sound” when programming in Qt/KDE and in order not to be dependent on a certain backend (GStreamer, Xine, QT, Direct*,…). And this decision, one has to respect.

What I do not understand is, why “KDE” gets so much attacked for this decision? I thought, KDE, Gnome, GStreamer, Linux, and so on, all that was so called free software projects? And I thought, free software is to a big part about choices. So, as a user, because of KDE’s decision to have Phonon: are you kept away from using GStreamer? No. And as a developer? No. But you have the choice to use Phonon, when it’s suitable for you, or GStreamer, or something else, otherwise.

I am glad, GStreamer exists. I am glad, KDE exists. So am I glad for Gnome, Xine and a lot of other free software. Remember that it’s always good to have competition in order to go further. But sometimes there is no need for competing. And even in a competition, one should always respect one’s competitor!

Thank you both Christian and Aaron for your good work and your commitment!

Reards,
D

Ps: No, English is not my native language, so I ask for your tolerance and hope you understand the meaning behind my words anyway. Correcctions are welcomed anyway.

After being introduced to Phonon’s API, I realzed it is Gstreamers API that made it complicated!

As Phonon seems a lot easier to get to work on different platforms as well,
im switching to Phonon.

As it happens, I installed Kubuntu on this laptop just yesterday. And at least on this machine, Phonon uses Xine by default. So much for the “Phonon always uses Gstreamer”-argument…. And what about KDE that is running on Windows or OS X?

Lee: “As a KDE user and developer….”. Aren’t you the “KDE-developer” who has submitted a total of 20 or so commits to KDE?

ideally you’d not just post an update of “this code changed”. I barely eer read that since it has no functional relevance for me. could you post walkthroughs on Youtube (like Diva used to do) so we can see with our own eyes how it works and what it can do? I know, tough assignment, but that’s what PR is for. Good luck!

Same applies also to Phonon, as it will trigger different kind of bugs with dshow/quicktime, so I am curious to see which approach will turn out to actually be worse.

And as they said, Phonon is a simple mm API, meant to simplify coding effort, which can ultimately lead to better players (especiall if a person doing it isn’t siklled enough to make it work well with a complex API). And I completely understand why they want to have option of using something else. (btw. my experience with gstreamer based players in Gnome is a bit of mixed bag).