OSNews

I don't think that's correct. Many KDE developers work for Trolltech^WNokia so they can influence the direction Qt goes. A good example of this would be the new QGraphicsView features in Qt 4.4 that were added at the request of Plasma developers.

Quite a bit of the work that's gone into Qt 4.3, 4.4, and 4.5 has been driven by KDE4.

It's true that they don't have the same relationship that GNOME has with GTK, though.

But if things were to go too badly, KDE could always just fork it. Then they would have complete control over it as well, they'd just need to come up with the developers.

Er, no. Tt/Nokia has maybe 2 or 3 developers working on KDE. KDE is their showcase "product", but their business hardly revolves around it.

Certainly they draw from KDE, such as their adoption of phonon, but that just makes sense, it's a reciprocal arrangement. But Qt is hardly controlled by KDE.

The LGPL goes against FSF principles, the only reason for it's existence is in the case that a particular set of libraries or framework cannot offer enough capability or functionality over existing proprietary options, it's an acceptable compromise. Qt doesn't seem to have that issue, and has managed to provide GPL *or* commercial licensing for some years now.

GTK, on the other hand, requires LGPL, because people would likely not pay for it. That's not to say that it's not a capable toolkit, just that it doesn't offer enough over alternatives to justify paying for it. Things like roadmaps and centralized support do mean something for many developers.

So why would Nokia LGPL it and turn it over to Gnome? Makes no sense.


[/q]

Gnome does not own GTK, *technically* or not. GTK was a graphics toolkit developed for GIMP, and it's now bundled with a bunch of other separately maintained packages and libraries as a development environment. No single organization *owns* GTK, and that is part of the problem.

Several months prior to Nokia acquiring Tt, they lambasted the fact that GTK had no direction. The Gnome developers are arguing over what direction GTK should take, with the upcoming version. The recent discussions about Gnome 3.0, and more relevantly GTK 3.0, has led to many posts from developers amounting to "about time" and "are we going to fix xxx?" It's one thing to say that the community "owns" GTK and controls it's destiny, it's an entirely different thing to see that put into play. Even the KDE devs realized through the challenges of KDE 4.0 that developers tend to focus on features, and nobody wants to work on the un-sexy low-level library work.

At the very least KDE has Tt taking care of much of the grunt work that OSS developers tend to shun. That's the kind of thing that goes into spit and polish, as well as stability.

I'm not trying to diminish GTK, but please don't dismiss Qt by saying "but GTK is free and open and owned by the community!". The community likes to talk about GTK, but few of them are actually investing the time and energy to drive it forward. The emphasis seems to be "let's just work with what we've got".

As I said above, Qt doesn't need the LGPL, because it offers enough that developers will pay the commercial license, or forgo that to utilize the GPL (or any of the other free licenses it is available under). The cross-platform capabilities alone, which span from platforms like *nix, Win and OSX down to portable devices, is staggering, and not something to be easily dismissed because it's not "free".

IBM, RH and Sun are interested in GTK as a framework for their various flavors of what Java should be. Novell wants GTK as a framework for mono. The community is going to have to step up if they want GTK to move forward from what it is already, or cede control to the the corporates they think they're protecting themselves against.

Otherwise, Gnome will never really control their own destiny, and that would be a shame.

Just my 2c...

I thought that GTK key developers now all work for Imendio.

Qt is licensed under GPL v3.

If Nokia decided to take Qt in a direction that was unsuitable for KDE, KDE could just fork the code and call it something else (say, for argument's sake ... cutie) and carry on.