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.

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

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.

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.

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.

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.

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.

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.

“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 ..