GNOME & Intel Developers Plan The Wayland Future

[RahulSundaram]

Plenty of KDE subprojects depend on glib which represents back-end stuff of GTK just as Qt has non-GUI modules but Gnome would never ever depend on them because Gnome people are arrogant NIH pricks.

Name calling just reflects poorly on you. The real reason is that glib is widely used by many C projects including Qemu which has no relationship with GNOME however for C++ programs, Boost remains the more widely used third party library and C++11 has standardized a lot of those features as well. So the non gui parts of Qt didn't get as much adoption.

[Guest]

Looking at those claims made in the links confirms that Gnome did what was right. Saying no is not NIH, if what is offered is wrong or bad. Today Canonical's intentions are completely exposed. They want to control as much as possible. Random specs tossed over the wall does not do it. No matter if it is for notifications or a display protocol. KDE got fooled last time, but they did not do it with MIR.

There were more situations in the past when gnome team didn't accept KDE technologies, but written similar things on their own. I don't remember correctly what was that, but one of it could be related to dbus and another one could be gstreamer.

And please do carefully read your last link. Was systemd a wrong choice? I think it is quite evident that Gnome did what was right. Systemd proved to do everything that the alternatives never reached. Overall Gnome have shown a very good judgement.

It was just example of NIH. However, systemd is not a gnome project.

[TheBlackCat]

Today it is quite evident that Gstreamer was the right bet.

Gstreamer never was and never can be the right bet. KDE has an ABI compatibility guarantee. They could not use gstreamer directly because it was going to, and did, break API (not to mention ABI) multiple times during the KDE SC 4 cycle. Phonon is a way to cover over these API breaks so applications don't have to deal with it. They would have to do this no matter what if they wanted to support gstreamer, and they had to make it flexible enough to support multiple APIs because it had to be able to support distros running multiple versions of gstreamer, and if they are going to go that route they might as well make it API agnostic, which is what they did.

Gstreamer devs originally supported this approach, but later changed their mind and said it was a bad idea, refusing to provide the support for it they had earlier promised.

I also you completely ignored the part about dbus. I mentioned a bunch of other examples earlier in the thread but still haven't gotten a response to any of them.

[kigurai]

Gstreamer never was and never can be the right bet. KDE has an ABI compatibility guarantee. They could not use gstreamer directly because it was going to, and did, break API (not to mention ABI) multiple times during the KDE SC 4 cycle. Phonon is a way to cover over these API breaks so applications don't have to deal with it. They would have to do this no matter what if they wanted to support gstreamer, and they had to make it flexible enough to support multiple APIs because it had to be able to support distros running multiple versions of gstreamer, and if they are going to go that route they might as well make it API agnostic, which is what they did.

Why is it that KDE hit these ABI/API problems in gstreamer (which I failed to find any reference to, maybe my Google-fu is weak) but GNOME doesn't?
I am asking not to imply that KDE is doing something wrong here, but rather curiosity from a software engineering POV.

Also, I think this discussion pretty much derailed a few pages ago since there is basically only talk about semantics and grasping of straws to prove some kind of point.

[danielnez1]

Maybe it is time for you to go all MIR? After all, the only difference between MIR and Qt is 15 years of social bribe. Contributor agreements are contributor agreements. And pigs are pigs. Allways.

You seem to forget the legal agreements that are in place with Qt in the event of Digia discontinuing the free edition. Also, trying to compare a half baked, NIH-tastic display server to a mature, proven and widely used application framework is pushing it a bit, but I guess thats how you roll.

[energyman]

Why is it that KDE hit these ABI/API problems in gstreamer (which I failed to find any reference to, maybe my Google-fu is weak) but GNOME doesn't?
I am asking not to imply that KDE is doing something wrong here, but rather curiosity from a software engineering POV.

Also, I think this discussion pretty much derailed a few pages ago since there is basically only talk about semantics and grasping of straws to prove some kind of point.

because gnome does constantly break stuff.

I also remember gnome betting everything on CORBA - which was too complex, bloated and unnecessary. Kde develeped dcop. You could do everything with dcop. Script any KDE application of your choice. Window placement. Everything. Want to change the mixer setting of one app with your phone via bluetooth? With dcop that was EASY.

Gnome of course was unable to accept something written by the KDE camp and pushed for dbus. KDE agreed to use dbus for KDE4. And that had to wade through molasses because gnome tried to make dbus as gnome-only and kde-unfriendly as possible.

And whoever wrote that gnome is a driving force behind wayland: please pull your head out of your behind.

[energyman]

Yes that is true. KDE has to stay NIH because they refuse to do major releases or target what ever parallel-installable version of Gstreamer. Instead they added an abstraction and made the test matrix explode. More code, more testings, less quality and a destiny as grave as aRts. No wonder the prime phonon developer went for cross-dressing instead of cross-backend abstractions. I would do the same thing.

really? because you know - phonon just works.

Unlike gstreamer.

[danielnez1]

You seem to forget the legal agreement is no threat to Digia. All they need to do is making a yearly release. It is so easy they can do it with a cronjob. And what happens if they fail? After a three months notification time KDE can do a relicense for the free editon only on desktop linux. That is it. That is as weak as it gets. The agreement was not done to protect freedom, it was red herring tactics. And you Sir is dragging it. A pig is still a pig even if you add lip stick or "legal agreements".

How am I dragging it? You are the one who seems to get awfully hot under the collar about Qt/KDE and have a seemingly impulsive need to spread FUD about them. I cant help think you are shill. Even if the free edition is limited to Linux, Digia cannot retrospectively withdraw the LGPL on the versions of Qt that would pre-date a licence change.

Mark Shuttleworth is greatly inspired by Qt. Getting people to sign contributor agreements AND praise you product is the ultimate goal. He just needs to learn about PR from Qt. Social bribing plus lock-in for MIR can get him the next Qt. All he needs is some fanboys who will defend the contributor agreements. Some one like you. Because that is how Qt and soon MIR roll.

IMO Mr Shuttleworth is a force unto himself and is more than capable of generating his own hot air. To pull you away from you delusion, I don't see how Qt needs to spin any PR - it is just a application framework after all.

[kigurai]

because gnome does constantly break stuff.

Like what? As a user I have never really experienced it. And I've been using Gnome for a quite a long time.

I also remember gnome betting everything on CORBA - which was too complex, bloated and unnecessary. Kde develeped dcop. You could do everything with dcop. Script any KDE application of your choice. Window placement. Everything. Want to change the mixer setting of one app with your phone via bluetooth? With dcop that was EASY.

Uhm, what has that to do with the underlying IPC mechanism? That should be a matter of applications listening to certain messages. If you can't do something with D-bus that you could do with dcop, then that sounds like a regression in the application in question.

Gnome of course was unable to accept something written by the KDE camp and pushed for dbus. KDE agreed to use dbus for KDE4. And that had to wade through molasses because gnome tried to make dbus as gnome-only and kde-unfriendly as possible.

References? Seems like a lot of people was in favor of the switch. I found a quote by aseigo: "the bit about d-bus was not saying dcop should have been picked up. i completely understand why d-bus is there; in fact, i was one of the early proponents of using it instead of dcop in kde." (see comment at http://aseigo.blogspot.se/2007/05/wh...ick-title.html).

[Teho]

You need to understand the whole gstreamer deal. KDE tried to do media support on aRts, and it failed. After that Gstreamer was proposed as a new crossdesktop attempt to solve the matter. KDE bailed and went NIHy. Instead KDE went for Phonon so they could use what ever media framework they wanted. Today it is quite evident that Gstreamer was the right bet. So all the Gstreamer fuzz could have been avoided if KDE made better choices in the past. Today Gstreamer is largely accepted in KDE.

Eh...? Just because GStreamer might the right choise today doesn't mean it was five years ago. For example there was no guarantee that the API would stay stable for the life time of KDE SC 4.0 (which btw it didn't altough it lasted quite well) but also the cross-platform support was lacking (especially the Windows support). Phonon allowed KDE to use the native multimedia frameworks of the operating system which kinda makes sense. Also it's hardly NIH when Phonon is designed to use already existing frameworks. It's just an abstraction layer that makes writing multimedia applications dead easy.

This is just yet another example of KDE making poor choices. So don't expect others to adapt to what ever they offer. There is no reason to hate Gstreamer, hate KDE's poor handling.

Quite a few Qt projects adopted Phonon even outside of KDE like the Tomahawk and Minitube players... because it makes sense for a cross platform applications. I'm not sure if it's still needed but it made sense when the project was started.