thin layers

Apparently Aaron had to answer the Why isn’t Phonon useless? question yet again. I guess when something is known for abstractionitis, it deserve that.

What I’m going to rant here though is about abstractions, that claim to be “thin layers” over something else and that makes them “good” because they can switch “backends” easily and then are “more flexible”. In case you don’t know what I’m talking about, here’s some examples: Phonon, XUL, Cairo

The biggest problem abstractions have is the lowest common denominator problem. You need a fallback mechanism if one of your backends doesn’t implement your feature. Most of the time, this fallback mechanism is not implemented, so using it ends up either being a “query capability and only use it if available” dance in applications or it just does nothing and users on weird backends (like BSD ;)) wonder why your application doesn’t work.

And even if you have a fallback mechanism, it often is very suboptimal and behaves wrong when compared to “native” output. Firefox’s awesomebar dropdown still looks totally out of place in GNOME compared to Epiphany’s and sometimes selecting text in cairo-generated PDFs is impossible, because the text was rendered using an image fallback.

Another similar problem is that you have to limit the API you design to the backends. You cannot sensibly make use of a real cool feature if most of your backends don’t support it – or you have to implement it yourself for all the backends. Depending on your choice, you either end up with unhappy users or N times as much work.

In the same vein there’s the problem with additional API burdened upon the user to properly support all backends. Cairo is going to gain the useful feature to mark text as a link or attach the riginal JPEG data to an image, so the PDF and SVG backends can include this information. However, this information is completely useless if you output to the screen.

And finally you’re writing a lot of code – mostly compatibiltiy code matching your API with the backends or fallback mechanisms for their unimplemented features. So you have to ask yourself if the “thin layer” you’re writing is really that thin or if you’d better use the underlying features directly. From my experience the answer usually is to use the underlying feature directly unless the “thin layer” adds some substantial features itself.

60 comments ↓

#1 Adam on 10.29.08 at 12:06

Sigh. Another wonderful example of Open Source trying to use techincal solutions (an abstraction layer) to solve social problems (working together).

#2 Gaute Lindkvist on 10.29.08 at 12:41

Good summary of the situation and I also concur with Adam’s reasoning for WHY this happens.

It is a complete cop out. Because Aaron Seigo is unsure of whether they can work together with GStreamer to create a solution that satisfies both camps, they simply try to abstract the problem away.

No current backends for Phonon on Linux/UNIX are perfect, neither is GStreamer. But instead of helping fix this Phonon increases the chance that there will be NO great backends. No matter how much you abstract away, Phonon will never be any better than the backend you are using.

#3 Janne on 10.29.08 at 13:17

Why can’t you people simply accept the fact that not everyone uses Gstreamer? Or that other people are under no obligation to use Gstreamer? KDE runs on other platforms that use other audio-systems than Gstreamer by default. So they have a system that allows KDE-apps to use the existing audio-system, as opposed to forcing the user to install Gstreamer, and running it side-by-side with the platforms native system.

Of course it would be ideal for Gstreamer-folks to force all those people to become Gstreamer-users. But that is not KDE’s job. KDE is under no obligation to push Gstreamer on anybody.

I really don’t understand why GNOME/Gstreamer-people whine so much about Phonon. I really don’t. They seem to have inflated sense of entitlement over this issue. And if someone decides to create a system that lets the user to use any audiosystem he prefers, they start to whine.
No, they would rather see Gstreamer be forced down everyone’s throat. Well, if you want to do that, go right ahead. But I fail to see why you expect KDE-folks to do it for you.

“No current backends for Phonon on Linux/UNIX are perfect”. Maybe. But KDE runs on other platforms besides Linux and UNIX. Their goal is to provide best possible experience on the platform the software happens to be running. That platform might be Linux. Or it might not. It might be OS X or Windows.

Seriously: this whining has gone on for way too long. Give it a rest already. KDE is under no obligation to use Gstreamer and Gstreamer alone. You are not entitled to have other unrelated projects use your software. If they use it, great. If they don’t, tough. Whining about it stupid and pointless.

#4 Xav on 10.29.08 at 14:11

Completely agree with you Benjamin. I’m tired of the endless layers that are added to abstract everything. Count how many you traverse between you app and the hardware for a simple printf in gnome-terminal, and be scared !

#5 Matthias Kretz on 10.29.08 at 14:16

Two short comments:
1. Phonon does add substantial features (mostly optional, so that the core stuff stays really thin)
2. You’re completely right about the lowest common denominator problem. It’s not a show-stopper, though. And carefully limiting your goals helps a lot there…

… is it only me or are many people actually understanding Phonon as a general purpose multimedia framework?

#6 Xav on 10.29.08 at 14:17

@Jeanne: the problem is just that instead of installing GStreamer, people are forced to install Phonon, which is the same thing (both can make use of the Windows audio subsystem) but less featureful and less well maintained.

#7 Janne on 10.29.08 at 14:30

“Jeanne: the problem is just that instead of installing GStreamer, people are forced to install Phonon, which is the same thing (both can make use of the Windows audio subsystem) but less featureful and less well maintained.”

The user is already installing KDE, and Phonon ships as part of KDE. your complaint would be more or less similar to “the user has to install XUL if he wants to use Firefox”. Or complaining about how installing GNOME requires the user to install GTK+.

If KDE used Gstreamer alone, they would have to install Gstreamer and use it side-by-side with their platforms existing sound-system. With Phonon they can keep on using the native system.

And fact remains that whining because KDE does not use Gstreamer and Gstreamer alone is stupid. Stupid, stupid, stupid. I just can’t understand the amount of whining Phonon has generated in Gstreamer-camp. Instead of whining, they should dedicate their energy on improving Gstreamer. Honestly, this whining makes them sound like a bunch of spoiled brats who get annoyed when someone decides to NOT use their software, and only their software. Like it or not, other people/projects are not forced to use Gstreamer, and if they think that they are, they have way overblown sense of entitlement.

#8 Paul on 10.29.08 at 14:58

“If KDE used Gstreamer alone, they would have to install Gstreamer and use it side-by-side with their platforms existing sound-system. With Phonon they can keep on using the native system.”

You seem to think that’s different to how GStreamer operates on such systems where there is a native solution.

As an aside, if we’re avoiding the whole concept of abstracting – should we also pack in the idea of GTKGlArea and GtkGLExt and just use raw X calls?

#9 fbk on 10.29.08 at 15:04

“Janne: Stupid, stupid, stupid.”

GStreamer *is* an abstraction library, and a very good one at that. The actual stupidity lies in abstracting the abstraction.

Like it or not, the decision to create Phonon was political. It’s the “G” that causes the problem.

#10 nona on 10.29.08 at 15:47

@Janne: “Stupid, stupid, stupid”

You seem to have a lot of pent up rage about this. Why don’t you at least try to understand why they are trying to say – you can still disagree. Calling them stupid whiners will neither help you nor them get the point.

- the best arguments I’ve seen from the pro-Phonon side are these from Michael Pyne:
http://lwn.net/Articles/183462/
http://lwn.net/Articles/300745/
In addition, they point out that even Gnome’s Totem has a Xine and a Gstreamer backend.

- I don’t believe the other side is the “anti-Phonon”, or “pro-Gstreamer” side, but rather the “pick-one-and-get-it-right” side. Choice can be bad, punting to the user is suboptimal. Phonon makes the easy things easy, but doesn’t make the hard things possible – they point you to the underlying libraries for that. They see Phonon as a leaky abstraction, an additional complication and possible source for bugs.

I’ll take Michael Pyne’s word for it that Phonon is indeed very lightweight, and that the effort involved in creating and maintaining it and its backend is outweighed by the API peace of mind KDE receives in return. Probably the right choice for KDE.

However, I’d like to eventually get to a full-featured framework that works well. Gstreamer is far from perfect (still got sync and performance issues), but it’s probably the only one that has the potential to become one. Getting all the stakeholders involved in GStreamer development would be good for the general quality of GStreamer, but would also make GStreamer attentive to the needs of the stakeholders (KDE). Probably the right choice for the whole community.

#11 Janne on 10.29.08 at 16:19

“You seem to think that’s different to how GStreamer operates on such systems where there is a native solution.”

But it’s also a lot more than a mere abstraction-layer for an existing system, now is it?

“Like it or not, the decision to create Phonon was political. It’s the “G” that causes the problem.”

Now that’s a load of bullshit if I ever saw one. There were valid reasons for implementing Phonon, and NIH was not one of them. For starters: some KDE-users are using Gstreamer at this very moment through Phonon. If KDE-folks wanted to avoid Gstreamer, they would be providing backends to every single multimedia-system out there, except Gstreamer. But that is not the case. In fact, they went ahead and created a Gstreamer-backend so Phonon could use Gstreamer.

Yeah, that sure sounds like “we don’t want to use that G-stuff!”… Or maybe not.

If KDE suffers from NIH (as you claim) how come they dropped DCOP (system KDE created) and adopted DBUS (system created outisde KDE and used by GNOME) instead?

The more Gstreamer-folks whine, the more apparent it becomes that they are in reality just saying “We DEMAND that everyone uses Gstreamer and nothing but Gstreamer!”.

And I really fail to see how this issue concerns GNOME/Gstreamer-folks at all. So you think KDE made a mistake? Fine, you are entitled to your opinion. Is that good enough reason for endless whining? Not in million years. The only reason for this constant whining can only be inflated sense of entitlement. There’s no other explanation for it.

Are Mozilla-folks constantly whining because Apple decided to build Safari on KHTML instead of Gecko? No. But for some reason when KDE decided to let the users (which could means distros or actual end-users) pick and choose a suitable multimedia-system for their needs, Gstreamer-folks started to whine. They obviously assumed that KDE will naturally adopt Gstreamer and only Gstreamer, and that they are entitled to add KDE-userbase to the Gstreamer-userbase. When that didn’t really happen, the whining started.

Seriously: get on with your lives already. World does not revolve around Gstreamer.

#12 Holger on 10.29.08 at 17:03

“Are Mozilla-folks constantly whining because Apple decided to build Safari on KHTML instead of Gecko?”

WebKit is actually a funny example. Why didn’t Qt abstract a HTML rendering engine, but bundle WebKit instead? Isn’t letting the end-user choose such an important thing? Actually, for HTML rendering, it would have made more sense to abstract WebKit (as this one does not itself abstract a platform rendering engine, like GStreamer abstracts a platform media engine where available).

Let me guess — that’s because WebKit originates from the K-side, not from the dark^W G-side.

#13 mtz on 10.29.08 at 18:08

i am one of those “simple KDE user” that is baffled by this bickering ..currently, i only use xine and mplayer as my multimedia backends and my kde4 install only has xine as its backend and i dont see any reason to complain ..

phonon makes sense to me as it can allow me to choose a back end of my choice and that will be xine first, mplayer second and something else i dont care to know at the moment because the first two havent disappointed me yet ..i would be pissed if i was forced to use gstreamer as iam sure someone else will be if they were forced to not use their backend of choice ..

amarok had a gstreamer backend together with others but they decided to go xine only in the official build and now they are going phonon only …wont the gstreamer benefit from this? they can now use gstreamer will amarok although they will have to go through phonon ..something they dont seem to like ..

i guess if you only have gstreamer as a multimedia backend, you will not see the point of an extra layer of abstraction ..but as others have said, not everbody(including me) uses gstreamer and in my case, i would rather have a system that allows me to choose btw xine and mplayer since these are they two backends that i currently use and i will hopefully undestandably will complain of i am forced to use only gstreamer in kde4

#14 Walther on 10.29.08 at 18:51

I’m a happy GNOME user and I love gstreamer and I also agree with the general message of the post. But please stop discussing phonon.

* KDE is their project. If they want to develop another layer of abstraction, let them.
* They are not saying everybody should add this extra layer. But KDE users/developers get it installed automatically. So it no extra dependency for them.
* Apparently gstreamer isn’t fullfilling all their needs on all platforms. We should make gstreamer better before complaining that other projects are not using it. It should be good enough to remove the xine backend from our own totem.

#15 Janne on 10.29.08 at 18:54

“WebKit is actually a funny example. Why didn’t Qt abstract a HTML rendering engine, but bundle WebKit instead?”

So is your argument basically that if KDE decides to create a wrapper for audio-system, they should create a wrapper for everything, including HTML-renderers? I’m sorry, but that argument is downright stupid.

And why do you think that KDE created Phonon so they could avoid using “GNOME-technology”? I mean, if that was their goal, they could have used some other audio-system instead. But they didn’t do that. They created Phonon, and they created a backend that allows Phonon to use Gstreamer (among other systems). So KDE DOES support using Gstreamer with Phonon. So how exactly does that fit in with your delusion that “KDE is trying to avoid Gstreamer!”, when they go out of their way to support Gstreamer in Phonon? This whole argument is getting so stupid that it’s hurting my brain!

It’s becoming plain as a day that the reason for this whining is because Gstreamer-folks have this weird idea that everyone must use their software and nothing else. If someone else decides to use something else, they start to whine. Grow up. All of you.

I REALLY don’t understand why GNOME-folks care what KDE-folks decide to do, as long as they are not actively harming GNOME (they aren’t, quite the contrary). They aren’t required to use your pet-projects. If they decide to take advantage of technology that originated in the GNOME-project, great! If they decide to use something else, too bad. But that’s still not a good reason to whine. KDE (or anyone else for that matter) is not required in any shape or form to use Gstreamer or any other piece of technology you happen to personally like.

And you didn’t address the DCOP/DBUS-argument at all… How does that fit with the idea that “KDE suffers from NIH!”? Answer: it doesn’t. In fact, it quite clearly shows that KDE is more than willing to take advantage of “third-party” technology if it makes sense to them.

#16 otte on 10.29.08 at 19:01

@mtz: No, you don’t want to let the user chose an implementation detail like the Phonon backend to use. It’s just a cause of lots of frustrations for the developers, when someone files bugs against amarok resulting from an unmaintained mplayer Phonon backend. People not having a clue when chosing is one of the main reasons for me removing as many backend options from my software as possible.

@Janne: You’d be a lot more interesting if you provided backup for your arguments, in particular the claim GStreamer devs are whining. As it stands, I enjoy your posts as much as reading /.

@Matthias: I think a lot of people think Phonon is supposed to be KDE’s answer to GStreamer – or at least the solution to all multimedia problems. And that almost certainly includes KDE and GNOME developers. I’m not even entirely sure about its scope when it comes to apps such as Cheese or MythTV.

#17 Dave T on 10.29.08 at 19:21

I’m pro Phonon on this one, Gstreamer is just too buggy for the time being and VLC appears to be the best and so I play my media through VLC, if GStreamer gets to parity or better I’d swap but after almost a decade of development on GStreamer and its still in the state its in then I wont hold my breath.

#18 Janne on 10.29.08 at 19:29

“You seem to have a lot of pent up rage about this.”

I wouldn’t say “rage”. But I do get pissed off whenever I see that someone is trying to force others to do as they say.

“Why don’t you at least try to understand why they are trying to say – you can still disagree.”

Well, what ARE they trying to say? All I see is whining over the fact that KDE decided to create Phonon, instead of directly supporting Gstreamer and only Gstreamer. Why would Gstreamer-folks be upset over that? Answer: because they think that everyone should use their software and only their software. Why else would they complain about this thing so much? Seriously?

I would understand if KDE did something that actively harmed Gstreamer. But they have done no such thing.

“Calling them stupid whiners will neither help you nor them get the point.”

I didn’t call them “stupid whiners”, I called them just whiners and I called the whining “stupid”.

And just to make things clear: I have no connection to KDE, I do use KDE (among other software), but that’s about it.

#19 Holger on 10.29.08 at 19:34

@Janne

“I’m sorry, but that argument is downright stupid.”

In fact, I was not making an argument. Just wondering what the difference is. So you may call the question “downright stupid”, if you want to.

“And why do you think that KDE created Phonon so they could avoid using “GNOME-technology”?”

Where did I write that? Dude, get your quoting right, and don’t try to put words into people’s mouth. This style tells more about you than anything else.

And by the way, judging from the plain word count for “stupid” and “whine” in your posts — frankly, to me, you’re the only one whining here.

#20 b0b on 10.29.08 at 19:39

The problem of layers over layers over layers is

- top layers is restricetd to the lowest common denominator
- more code => more bugs
- error handling between the layers. This is less easy to get right than it sounds
- dupplication of effort. For example under win32 you have the DirectSound back-end of phonon and the DirectSound back-end of gstreamer. Instead of having one that is rock solid let’s have both in different state of buggyness.

For more stupidity I propose someone code an abstraction of phonon as well as a phonon back-end for gstreamer. That would allow an infinite loop between back-ends.

#21 Janne on 10.29.08 at 19:41

“Janne: You’d be a lot more interesting if you provided backup for your arguments, in particular the claim GStreamer devs are whining. As it stands, I enjoy your posts as much as reading /.”

This blog-post we are commenting in is whining.

This is whining: http://blogs.gnome.org/uraeus/2008/09/25/in-the-land-of-silly-arguments/

This is whining: http://blogs.gnome.org/uraeus/2008/09/26/the-arguments-for-using-gstreamer/

Why does this blog-post and Christians blog-posts spend so much time talking about Phonon? Why are they getting their panties in a bunch over Phonon? Seriously? Why do they care at all what some other projects decides to do?

What sort of backups for my arguments should I provide here? This blog-entry is one argument, as are Christians blog-posts. All those blog-posts are about complaining about Phonon.

#22 Janne on 10.29.08 at 19:47

“In fact, I was not making an argument. Just wondering what the difference is.”

Well, one difference is that KDE had a HTML-library ready to go, while they had no working multimedia-framework.

“Where did I write that?”

You said that KDE does not want to use GNOME-technology. You were pretty specific about it. IF you want specific quote:

“Let me guess — that’s because WebKit originates from the K-side, not from the dark^W G-side.”

Seems pretty clear-cut to me…

“And by the way, judging from the plain word count for “stupid” and “whine” in your posts — frankly, to me, you’re the only one whining here.”

really? I’m not a developer in a highly-visible project who keeps writing blog-posts where I complain about actions taken by another high-visibility project, even though they do not directly affect me in any shape or form. Yes, that is whining.

I still haven’t received any satisfactory answer to my question: why are Gstreamer/GNOME-devels spending so much time complaining (I wont say “whining”, since it seems to annoy you) about Phonon? Seriously, why?

#23 Aaron Seigo on 10.29.08 at 20:14

Ben, besides your inaccurate and manic characterization of the topic I was actually addressing (as usual), you gloss over the actual issue (as usual). The challenge is writing sane application code that works on all our target platforms as configured today as well as in 5 years from now.

No media framework gets us there on its own, and that’s understandable since that’s not their scope.

It’s really a fairly simple concept.

@Holger: the reason for using WebKit directly is because it doesn’t require an operating system interface and actually is built for toolkit abstraction already.

#24 Holger on 10.29.08 at 20:25

@Janne:

No, I did not say that Phonon was created to avoid GNOME technology. I know about GStreamer backends, and D-Bus (for which I am especially happy).

I do however think that it would have had a much higher chance of going into Qt if it either didn’t have a G in the name, or wasn’t based on GObject/Glib. After all, the idea of the GStreamer core isn’t so much different to Phonon: Be small, highly portable, and abstract platform media where available. Real functionality can be plugged in, and does not reside in the core.

Besides that, GStreamer is not a GNOME project. It’s a fd.o project. In my oppinion, fd.o is the most important project on the linux desktop, and I am always unhappy to see them fail (which happens much too often).

Choice is good, but sometimes, it just ends up in fragmentation. I mean, if a third party application targetting linux whats to use audio, what should it use?

Not from a GNOME or GStreamer point of view (I am affiliated with neither), but from an independant software vendor point of view it would have been important if KDE had chosen to help shape GStreamer core to their needs instead of abstracting it yet again.

#25 randomguy3 on 10.29.08 at 21:33

The other reason for Phonon is that is provides a simple Qt-like interface for doing “play this file” or “play this stream” stuff. The API style is familiar to any Qt/KDE programmer (which a truly thin wrapper over GStreamer wouldn’t be) and there is none of the complexity needed to create, say, an audio editing application.

On top of that, GStreamer simply won’t play all of my audio files, no matter how I fiddle with it. Xine does (or almost, it doesn’t like some of the filenames on my non-UTF-8 system).

#26 Zun on 10.29.08 at 22:10

“Besides that, GStreamer is not a GNOME project. It’s a fd.o project.”

Fun fact: fd.o is where GNOME declares its technologies to be standards so it can poke fun at KDE for not supporting them. Most recently, Lennart’s sound-theme-spec. (“libcanberra implements a XDG spec, KNotify is KDE-specific, lalala”)

#27 blister on 10.29.08 at 22:44

Fun fact2: Phonon is not on fd.o. Because KDE doesnt dare it. Phonon has no value to QT software if they cant spoil the copyrights for profits.

Siego: here is a dare. Go back to KDEs biggest dependency and ask them about putting phonon on fd.o

Bring a cake.

#28 Matthias Kretz on 10.29.08 at 23:09

Ha ha, Mr. blister, Phonon on fd.o is very funny indeed. Why? Because anything with a Qt dependency never got anywhere near GNOME, it’s already very very hard (did it ever happen?) if it’s C++ without Qt deps.

I’ve gotten requests to put Phonon on fd.o. But I knew that this would just be asking for flame wars, nothing else.

OTOH many people expect KDE developers to embrace C APIs, or worse GObject style APIs. I tell you it’s causing actual pain to work with those APIs when you’re used to C++ and Qt APIs.

BTW, the copyright to Phonon belongs to me, a few other KDE people and Nokia. It is LGPL and still a KDE project.

“Siego: here is a dare. Go back to KDEs biggest dependency and ask them about putting phonon on fd.o” doesn’t make sense. Care to explain? BTW, it’s “Seigo”.

#29 Holger on 10.30.08 at 08:19

@Zun:

“Fun fact: fd.o is where GNOME declares its technologies to be standards so it can poke fun at KDE for not supporting them.”

Ah, witch hunting again. That’s fun to outsiders (like me).

Let me give an example: Back in 2004 I followed a discussion about a convention for asynchronous desktop notifications (like “new mail arrived”). Let me cut it short: As an ISV, on Linux, you can’t. Or say, you can on two of the three big desktops (GNOME and Xfce) which have implementations for the desktop notification specification. So when my KDE users ask why no notifications appear, I am answering: Install either the GNOME or Xfce notification daemon. Great deal.

I read somewhere vague comments that there’s light at the end of the tunnel, and the KDE will support the spec too (or even does already since recently). That’d be great. Maybe it’s worth having another look, 4 years later…

@Matthias Kretz

“it’s already very very hard (did it ever happen?) if it’s C++ without Qt deps”

*cough* WebKit *cough*

“OTOH many people expect KDE developers to embrace C APIs, or worse GObject style APIs. I tell you it’s causing actual pain to work with those APIs when you’re used to C++ and Qt APIs.”

I read that as “I don’t want to support interoperation, because it’s painful”. That’s completely valid, and good to know.

“BTW, the copyright to Phonon belongs to me, a few other KDE people and Nokia. It is LGPL and still a KDE project.”

A LGPL project with GPL dependencies (QtCore). Sounds like a lock-in trap to me. I’d like to learn to be wrong on this, though.

#30 Søren Hauberg on 10.30.08 at 08:21

“Janne: Why can’t you people simply accept the fact that not everyone uses Gstreamer? Or that other people are under no obligation to use Gstreamer?”

When KDE4 started, I think there was a lot of hope amongst gnome people, that KDE would be picking up some of the good gnome/fd.o technology, such that it could be improved. It is wonderful that KDE decided to use DBUS, because now we have a common API, and more people working on improving one of the core libraries. And there’s less code to maintain, now that the two desktops share a library. Everybody wins.

In the multimedia world, things are a little less clear. We have several competing frameworks (gstreamer, xine, vlc, mplayer) for playing files. When it comes to playback, gstreamer is probably the worst of these frameworks. But it is the only framework that has the potential to become a true multimedia framework. So, the gstreamer/gnome people were really hoping that KDE decided to embrace gstreamer fully, since that would have given gstreamer a boost. Now, if gstreamer doesn’t play file X, then KDE users will just use another backend. If gstreamer had been the only backend, then there would have been a greater chance of somebody fixing it.

So, there was a lot of hope in the gstreamer/gnome camp that KDE4 would embrace gstreamer, since that would have improved the quality of gstreamer. With phonon, gstreamer might get some new users, but it’ll hardly get new contributors. So, people are disappointed. Nobody is forcing anybody, there’s just a lot of disappointment.

#31 Matthias Kretz on 10.30.08 at 09:09

@Holger:

WebKit is on fd.o? I must be living behind the moon…

“I read that as “I don’t want to support interoperation, because it’s painful”.”

Please don’t put words in my mouth. Guess why I can talk about “work with those APIs”… It’s because I work on interoperation. It sometimes is painful and I could think of nicer things to do in my free time. I work on interoperability nevertheless.

“A LGPL project with GPL dependencies (QtCore). Sounds like a lock-in trap to me.”

Huh? Care to explain where the “trap” is?

#32 Holger on 10.30.08 at 09:18

@ Matthias Kretz
“WebKit is on fd.o? I must be living behind the moon…”

You talked about Qt-dependancies or C++ in general getting anywhere near GNOME. There you go.

“Huh? Care to explain where the “trap” is?”

If Phonon has GPL dependancies (as it is my understanding, which may be wrong), then anything using Phonon has to be GPL compatible. So basically, for the Phonon code itself, being GPL or LGPL is no difference, until all GPL dependancies are removed.

#33 Matthias Kretz on 10.30.08 at 09:43

@Holger
I was specifically talking about fd.o. But you’re of course right that WebKit did get GTK integration. It’s an interesting case, though. Would it ever had happened if “only” KDE were behind it – i.e. WebKit as it is now without the backing from Apple and others? Hard to tell, but interesting thought material.

Phonon being LGPL and Qt GPL (plus exceptions) obviously means that applications using the Open Source version of Qt need to follow the Qt license. But there’s also the possibility to buy a commercial license from Qt Software. With that you wouldn’t be able to use libphonon if it were GPL. In order to make it possible to have Phonon useful for Qt Software and have no trouble with copyright assignments for community involvement in Phonon, LGPL is the only sane choice (ok, more liberal licenses should also do). In that way you might call it a “strategic license”, like the FSF calls their LGPL projects.

But I still don’t understand the “trap” part. It’s not like developers program against libphonon and only at release time realize that they linked against GPLed Qt all the time…

#34 Zun on 10.30.08 at 09:45

@Holger

You are, in fact, wrong.

http://doc.trolltech.com/4.4/license-gpl-exceptions.html

If you now say that you wish you could develop proprietary apps with it for free, I’m going to point and laugh at you.

You also did not contest that GNOME declares fd.o standards unilaterally.

#35 Holger on 10.30.08 at 10:15

@ Matthias Kretz:

If I want to use Phonon, my application has to be GPL compatible (or licensed under a bunch of Nokia-declared licenses and fullfill some other demands), or buy a (very expensive) Qt license. While that’s fine for many use-cases, it is a no-go for others.

Telling people to either be GPL or buy Qt-licenses just to play some simple audio on Linux does not sound like the role-model solution to promote the Linux desktop to me.

@ Zun:

“If you now say that you wish you could develop proprietary apps with it for free, I’m going to point and laugh at you.”

No, I’ll take GStreamer for that. By the way, I couldn’t care less against whom you point and laugh.

There are people out there who would like to have commercial software ported to Linux. If your answer to the question “How do we play basic sound” is “either be GPL or buy a Qt license”, the reaction is likely to just drop the linux port.

“You also did not contest that GNOME declares fd.o standards unilaterally.”

You still didn’t understand that I’m not a GNOME guy. And I don’t care at all where desktop interoperability standards (or rather conventions) come from, as long as they exist. So if fd.o is so GNOMEish and bad, where’s the (better) replacement?

#36 im on 10.30.08 at 10:20

@Matthias Kretz
let say I want to use libA for my app. libA depends on libB, which depends on libC, ….

the trap is, as developer, I have to go throug the whole chain of layers to see if the licences are apropriate for my purposes.

I don’t have the time and interest to become a half-asses lawer, really.

#37 Matthias Kretz on 10.30.08 at 11:06

@Holger:
What use-cases are there for a Qt/KDE application that can neither be GPL compatible nor use a commercially licensed Qt version?

Who is “telling people to either be GPL or buy Qt-licenses just to play some simple audio on Linux”? Sounds stupid to me. Please don’t take it out of context. Phonon started as a KDE library. Guess what, KDE depends on Qt. Phonon then evolved into a library that was less coupled with KDE libraries but is still fully on top of Qt. Phonon is meant for developers using Qt already. They get an API that is familiar to them.

‘If your answer to the question “How do we play basic sound” is “either be GPL or buy a Qt license”‘

That’s a strawman argument. Nobody in his right mind will give that answer. Basic sound == libasound on Linux.

@im:
You’re missing the point here. If you use libphonon you know that you’re using Qt. And Qt isn’t just a lib with a few simple functions, it’s a comprehensive toolkit.

Or let me ask the follow-up questions:
a) Should a library never have dependencies?
b) A lib that depends on another one should not have a different license?
c) If somebody wants to write a lib for developers who can make use of it without any license issues but other developers can’t, the lib should never be written?

#38 Segedunum on 10.30.08 at 11:43

Heh, I found that really funny. When GStreamer actually matures into something usable, and the fanciful avenues that PulseAudio is wandering off into actually starts working, oh and when we get Linux audio working again, give us all a call, eh?

Until that day, I don’t call rewriting all your applications for yet another multimedia library a particularly good idea for anyone, and you’ve grabbed hold of a lot of examples in there that have nothing to do with the situation we find ourselves in regarding multimedia.

I think we might just all have to accept that people on the G side of things just don’t get that screwing your application developers over, forcing them to ship libraries like libegg or libsexy, or even just plain copying and pasting code in, is just a seriously bad and brain damaged idea.

You cannot sensibly make use of a real cool feature if most of your backends don’t support it – or you have to implement it yourself for all the backends.

Given the current situation I think most people would settle for sound actually coming out of their speakers ;-). Yes, there will likely be some esoteric media feature that some people might want, but then, that’s not what Phonon was designed for. I don’t know whether you realise, but the situation is that bad.

And finally you’re writing a lot of code – mostly compatibiltiy code matching your API with the backends or fallback mechanisms for their unimplemented features.

The problem is that you are going to write this stuff anyway, and worse, each application developer will have to do that themselves. Good luck. With Phonon, they get together in one place in the desktop environment itself and solve it there.

If you want developers and users to be screwed over by the media situation on open source platforms then fine, but Qt and KDE developers sensibly don’t.

#39 im on 10.30.08 at 11:55

@Matthias Kretz
maybe I was not clear enough. I’m nt reffering to phonon/qt. The problem that I, as ISV, am facing is the “hidden” restriction deep down the chain of libs.
I like to be sure that if I want to use libA, that is LGPL, I will not get beating bei libF under GPL. libA abstracts the technical issues, which why I choose it, however, it doesn’t “abstracts” the license issues. That botthers me.

a) Should a library never have dependencies?
Silly question.

b) A lib that depends on another one should not have a different license?
It shouldn’t. PHP, Python, TCL rely heavely on third-party libs. They pay special care about the licenses. For me, a big win.

c) If somebody wants to write a lib for developers who can make use of it without any license issues but other developers can’t, the lib should never be written?
Do it. I’ll be that last who want to prevent you from doing it. Be clear in the communication about the license dependencies, 3 lines in plain english or so.

#40 Segedunum on 10.30.08 at 12:08

@Holger

No, I’ll take GStreamer for that. By the way, I couldn’t care less against whom you point and laugh.

GStreamer is one of the pieces of the jigsaw that got us into this mess. A decade on it still hasn’t proved itself to be the reliable multimedia tool that was promised, and we’ve even got brain damage like PulseAudio making things work far less and trying to solve problems most people just don’t care about. There’s a lot of ideology from some people about how multimedia should work, but unfortunately it doesn’t work. Even ten years later, people still use the word ‘potential’ with GStreamer. Go figure.

Good luck with that, and yer, we’re laughing. Users and developers aren’t unfortunately.

@im

the trap is, as developer, I have to go throug the whole chain of layers to see if the licences are apropriate for my purposes.

You haven’t got a clue what you’re talking about, and all I can see there is some convoluted and rather sad way of trying to claim that multimedia on Linux and open source platforms will be tied to Qt and tied to people buying Qt licenses just because Phonon exists. That’s so full of shit it isn’t even funny, but it’s not like we haven’t heard that message before ;-).

#41 Segedunum on 10.30.08 at 12:30

@Holger

Let me give an example: Back in 2004 I followed a discussion about a convention for asynchronous desktop notifications (like “new mail arrived”).

That’s funny, because the only thing I know of for that was Galago and that was a solution for Gnome’s notification deficiencies from a development perspective, not as a universal cross-desktop solution (although it was dressed as such). I haven’t even heard anything about it in quite a while and we even get the helpful message that Qt bindings will appear ‘in time’ (http://www.galago-project.org/about.php), but KDE is just expected to adopt it in whatever form. Go figure.

So when my KDE users ask why no notifications appear, I am answering: Install either the GNOME or Xfce notification daemon. Great deal.

Ha, ha, ha. You know why that is? Because Xfce and Gnome tend to use exactly the same GTK based applications, so yer, it probably is going to work. It has absolutely nothing to do with Xfce implementing any kind of specification that KDE didn’t, therefore (by your own implication) making KDE a despicable desktop environment that doesn’t want cross-desktop collaboration. Your point, whatever it is, so so null and void it isn’t even funny.

You might as well say “If you rewrite everything in GTK you’ll get notifications between applications” (untrue, but what the hell). Irony doesn’t cut it.

#42 Segedunum on 10.30.08 at 12:41

@fbk

GStreamer *is* an abstraction library, and a very good one at that. The actual stupidity lies in abstracting the abstraction.

GStreamer is not an abstraction library to anything but itself. The attitude here is that everyone should just link to GStreamer and be happy, but alas, GStreamer != a universal multimedia solution for everyone after all this time. If the GStreamer people want to write code to change that then fine, but they aren’t going to change it by banging away on blogs criticising anyone who doesn’t use it.

The mainstay of multimedia applications on Linux right now consists of Xine, MPlayer, VLC and applications like MythTV that have no reason whatsoever to use GStreamer. Persuade those people to use GStreamer. The reason why those applications are well used is because they actually work and they provide useful functionality. Initiatives like GStreamer and PulseAudio are just an awful lot of effort and pain to stand still.

#43 wtay on 10.30.08 at 14:09

@all please people, file bugs for GStreamer things that don’t work correctly for you. Saying ‘it does not work’ is not a valid bug report, All sync and playback/speed issues are usually quickly fixed nowadays, it’s worth to file bugs.

#44 Holger on 10.30.08 at 14:38

@Segedunum

“Because Xfce and Gnome tend to use exactly the same GTK based applications, so yer, it probably is going to work”

You don’t get the point. At all. Maybe it was too much transfer-thinking that I asked for when mentioning the notification spec.

That spec, in contrast e.g. to sound, is just a D-Bus API specification. That has nothing to do with GTK+. At all. You don’t need any Qt bindings, except Qt-DBus. You could just let KNotify expose those 3 or so interfaces on the session bus.

But as I said, I heard that exactly this might have been done recently. That would be great.

#45 Segedunum on 10.30.08 at 15:46

@Holger

You don’t get the point. At all.

What point would that be exactly?

That has nothing to do with GTK+. At all.

Maybe reading and understanding is too much of a problem:

http://www.galago-project.org/about.php

“Currently, Gtk+ widgets are available in our Subversion repository under the module name libgalago-gtk. Qt widgets will be available in time.”

You could just let KNotify expose those 3 or so interfaces on the session bus.

No, you can’t. At all. I’m afraid you can’t just say “Hey, we’ve come up with this notification thing that we have implemented and we’ve integrated it with what we have so you should start using it as well”. There’s more to supporting something than throwing things through DBUS and proclaiming it as a standard. You need to provide a wider infrastructure to support it and your application framework needs to know how to deal with it, events need to be mapped on to it in a compatible way and so on and so forth. I take it they didn’t pay attention to KNotify’s pre-existing events before the started Galago? ;-)

You prove everyone’s point when you start getting into pissing matches about KDE not supporting every tin-pot project that has sprung up in the name of cross-desktop interoperability. It’s purely defensive, and there is ample evidence for the contrary – adoption of DBUS, adoption of icon naming spec (helpfully called the Tango icon specification by many ;-)) and so on and so forth.

Galago was about improving Gnome’s own deficiencies and precious little else, and from that perspective, KNotify had been doing all that for quite a while ;-).

#46 Leo S on 10.30.08 at 15:48

Wow.. you guys really can’t just let it go eh? Who cares what KDE uses?

Gnome devs can rest easy in the knowledge that their apps using gstreamer directly will be slightly more efficient than qt/kde apps using phonon.
Qt/KDE devs can rest easy knowing they have a nice, simple, familiar API (don’t underestimate this, remember developers, developers, developers) that is safe from whatever happens to the backend.

Everyone’s happy. So will everyone shut the hell up about this already?

#47 Segedunum on 10.30.08 at 15:53

file bugs for GStreamer things that don’t work correctly for you. Saying ‘it does not work’ is not a valid bug report

People have been doing that for the best part of ten years now, most of the bugs are extremely hard to reproduce (certainly the seek stuff is) in a bug report and there comes a point where you have to ask yourself if there is something fundamentally wrong. Most people generally just switch their backend to Xine or something.

#48 Holger on 10.30.08 at 16:04

@ Segedunum:

“Maybe reading and understanding is too much of a problem:”

(plus a link to Galago (!)).

Maybe you’re missing that I am not talking about Galago, but about asynchronous desktop notifications. You _do_not_need_ any Galago widgets for that. Really, trust me on this. It’s the other way round: Galago makes use of the spec. It seems that you did in fact read, but forgot the “understanding” part.

The fact that the spec was written by Galago people manifests only that this kind of cross-desktop functionality was so far missing. It does not mean (4th time now) that you need Galago widgets for that.

“No, you can’t.”

But it seems like KDE people did. Hooray!

“I take it they didn’t pay attention to KNotify’s pre-existing events before the started Galago?”

Yes, they did, but the discussion did not lead to a solution, see e.g. http://lists.freedesktop.org/pipermail/xdg/2004-July/002682.html

You name some successes, and especially having D-Bus as a common IPC mechanism could help improve things a lot. That’s a great success for fd.o for which I am very happy. Tango is btw another fun example. Denied and laughed at as butt ugly, personally, I can hardly spot the difference between Oxygen and Tango icons. Which is a good thing.

#49 wtay on 10.30.08 at 16:05

@Segedunum

I agree that before the GStreamer 0.10 release we did not have the multithreading, seeking and synchronisation under control but that is certainly no longer the case since over more than 3 years.

I can understand a certain frustration but I can only ask to report problems. With the design we have today we feel confident we can fix all those problems –when we know about them–.

#50 Kevin Krammer on 10.30.08 at 18:26

I think I agree with Benjamin on the general problems of abstractions, however sometimes an abstraction is the only way to take the burder of interoperability onto yourself instead of pushingit onto others.

Take for example PackageKit. Of course it could just mandate RPM or dpkg or whatever and not do any kind of abstracted backendfrontend thing, but this would put the interoperability burden onto somebody else, e.g. the OSV currently not using the chosen package manager.

Or in the case of Cairo, the developers of the painting API could of course mandate OpenGL as the only rendering path, but this would probably be hard for people with older systems, remote desktop requirements or mobile devices.

Or in the case of Phonon, the developers of the Qt/KDE API could of course mandate GStreamer, but that would put the burden on GStreamer to stay API and ABI compatible for the required lifetime or do feature development on two versions.

#51 mtz on 10.30.08 at 19:50

@Kevin

“Or in the case of Phonon, the developers of the Qt/KDE API could of course mandate GStreamer, but that would put the burden on GStreamer to stay API and ABI compatible for the required lifetime or do feature development on two versions.”

or kde could totally go one backend only and choose xine or mplayer ..completely sidelining gstreamer ..what will gstreamer guys and girls say about that?

.. and this is the situation kde dont want to be at and chose to use phonon to shield itself from 1. forcing its users to use a backend they dont want 2. putting all their efforts in one backend without any guarantees that that backend will always be availabe in a state that will make in convenient to kde as a desktop env and to kde developers ..

gstreamer may sit well with the rest of gnome environment but its just as foreign as any another multimedia backends like xine,mplayer and vlc among others ..

what make people think that if kde4 went with one backend, gstreamer will be the default choice? i have xine as the only backend in my kde4 install ..

there are people out there who do not use gstreamer as their backend of choice, personally,on my system, the best gstreamer can do is at the third place behind xine(first choice) and mplayer(Second choice) ..

gstreamer is not for everbody and i think phonon is making a right move in not forcing anybody into using a backend they dont want ..

#52 Morty on 10.30.08 at 21:35

Funniest thing with all the whining and NIH accusations regarding GStreamer and Phonon, are that GStreamer are one of the largest NIH examples in FOSS. Before GStreamer was started, there already was a multimedia standard widely used and avaliable for addaption by the Gnome project. But they chose to do a NIH, and start their own.

By all means aRts was not perfect, but instead of helping fix this GStreamer increased the chance that there would be NO great backends. And 10 years later this is still true. Had the amount of work, resources and design improvements applied to GStreamer been spent on aRts, the situation would most likely have been different.

Also funny to consider that one of the main issues applied to aRts at that time, now are one of the hottest developments regarding sound on the open desktop the last year, PulseAudio.

#53 tpm on 10.31.08 at 10:11

Morty:

GStreamer has very little to do with aRts or PulseAudio in terms of problem space (or otherwise); it was never meant to be a sound daemon or replace one, and doesn’t.

#54 Morty on 10.31.08 at 10:38

tpm:

No GStreamer and aRts overlap very much in functionality, since aRts was more than a sound daemon. The functional replacement for aRts is GStreamer plus PulseAudio(or dmix, or soundcard with hardware mixing if you like). So aRts did more. But the essential problem space is the same, give the user a good infrastructure to handle sound and multimedia.

And that some of the scope of GStreamer transcend that of what aRts did 10 years past, does not change that. Those capabilities could easily been added to aRts too, as the need become apparent.

#55 wtay on 10.31.08 at 11:18

@Morty:

aRts was designed as a sound synthesis framework. It did this quite well given the technology of its time. Sound synthesis is only a small part of the multimedia problem space and is also orthogonal to the actual audio output.

We now know that the proper design is to have:

1) a good user space sound server that does just that (and that’s already complicated).
2) have synthesis, decoding, encoding, filters,… algorithms and ways to execute them
3) bind it all together with a multimedia framework.
An analogy is 1) the X server/DRI 2) pixel shaders in the GPU, 3) OpenGL API. Another one: 1) pulseaudio 2) ffmpeg, libspeex, libvorbis, libogg, libx264, libalsa…, 3) GStreamer

aRts mixed 1) and parts of 2) but it was not sufficiently abstracted to move forward and become 3). See also http://www.arts-project.org/doc/arts-maintenance.html for more information.

#56 Kevin Krammer on 10.31.08 at 18:09

@mtz:
“or kde could totally go one backend only and choose xine or mplayer ..completely sidelining gstreamer”

That doesn’t change anything regarding my argument. Mandating any specific implementation moves the burden to the developers of that implementation.

“…without any guarantees that that backend will always be availabe in a state…”

This is exactly what I wrote. Not doing an abstraction moves the burden of keeping updated and being stable to the developers of the chosen single dependency.

I am not arguming about the additional bonus of having the option to switch to a better implementation at any time, I am just noting that abstraction is also a way of carrying the load of compatability on ones own shoulders instead of conveniently offloading it to somebody else.

#57 Segedunum on 11.01.08 at 15:00

@Holger

Maybe you’re missing that I am not talking about Galago, but about asynchronous desktop notifications.

And? I won’t comment on this much further because it’s way off tangent, it’s merely an avenue to follow to try and tell us how bad KDE is at following all these lovely FD standards and it completely ignores that it isn’t just a case of using three interfaces. Integration is never that simple. You need to know what the other side is saying.

But it seems like KDE people did.

Looks as though they have, which is great, and sometimes it just takes time to do. It’s not that there is no evidence of a commitment to do it. Kind of mutes the point really ;-).

You name some successes, and especially having D-Bus as a common IPC mechanism could help improve things a lot.

The problem I have with Gnome is that it doesn’t really use IPC like KDE does. DCOP, and now DBUS, are very critical to KDE actually working and you can’t get a bigger commitment than that. DBUS use elsewhere is generally very application dependant, but it’s been very, very useful to have an IPC system that can go beyond each desktop environment and allow better communication between subsystems.

#58 Michael "Galago" Howell on 11.10.08 at 01:09

@Segedunum and @Holger: You are arguing on a moot point… A Galago interface has been implemented and will be included in KDE4.2 (it’s in trunk). From an architects POV, KNotify now supports outputting to Galago, which could be the accompanying notification desktop applet or the GNOME equivalent. KDE applications get native notification on GNOME, GNOME applications get native notification on KDE.

And yes, I know how incredibly off-topic this is, except that it shows (again) that KDE is willing to adopt GNOME-originated technology.

#59 Segedunum on 11.10.08 at 10:32

Cheers Michael, wasn’t sure on the status of Galago or if it was still to be used. It’s nice to know that it’s happening. What’s not so nice is people now picking on the ‘time scales’ that these things are happening.

#60 Jonas on 11.15.08 at 11:19

Excellent post, but for one thing which I have to point out: I don’t think it’s fair to list XUL as a case of abstractionitis. XUL is a toolkit on the same level as GTK and QT. I assume you think of XUL as an abstraction because of it’s ability to use e.g. GTK for rendering when running in a GTK-native environment, but QT can also do that, and so can GTK with QT.

I just don’t see what makes XUL any more of an abstraction than QT or GTK. It’s a toolkit. You might argue that it’s a redundant toolkit, but I don’t see how it’s just an abstraction layer around other toolkits.