KDE Developers Discuss Merging Libraries With Qt 196
An anonymous reader writes "A proposal has been brought up with KDE developers by Cornelius Schumacher to merge the KDE libraries with the upstream Qt project. This could potentially lead to KDE5 coming about sooner than anticipated, but there's very mixed views on whether merging kdelibs with Qt would actually be beneficial to the KDE project, which has already led to two lengthy mailing list talks (the first and second threads). What do you think?"
No! (Score:4, Interesting)
I'll fork it if I have too!
God no (Score:5, Interesting)
After seeing the last attempt at cooperation over Phonon - which was half-implemented in Qt, then Nokia went with Qt Multimedia while KDE continued evolving Phonon but all the new things aren't in Qt I wouldn't want them to try. Some of the functionality that exists on the KDE layer should be pushed down into Qt, but most should stay out otherwise there will be far too much platform in the toolkit.
Re:KDE needs some competition. (Score:3, Interesting)
GNUstep has a lot of potential. However, there is a paucity of applications actually written for GNUstep in Objective-c and it is really going nowhere.
They should freeze the main libraries and infrastructure, and contrite on getting a nice web browser made. This is one thing that does not really exist yet. Yeah, you can run FireFox under Windowmaker, but it's ugly and bad. What they need is a lean, mean, webkit-based browser that is like a lite version of Safari.
Then we can bootstrap a few other necessary apps.
Re:Probably a non-starter due to copyright assignm (Score:3, Interesting)
It's not just the copyright assignment: it's also the fact that Qt is now controlled by a huge organization (much like OO.o is). Nokias goals for Qt may already be quite different to KDEs goals for kdelibs, and if something is certain it's that corporate interests change. We cannot tell what Nokia wants to do with Qt next year, or in in five years.
Everybody is in agreement on where Nokia is. Mobile is tier one, everything else is tier two, the question is really if KDE should keep making thin convenience classes like KIcon on top of Qt's QIcon or just hand that stuff to Nokia. By being in kdelibs it should already be LGPL, so really the question is can Nokia do something useful with a little desktop-oriented code they could put in a fully proprietary app instead of a proprietary app using LGPL libraries. I suppose it's possible, but I think it's more principles than practice that is the problem here.
P.S. Technically it's not a copyright assignment, but they demand full relicensing rights so in practice they can do whatever they want.
Re:Quanta? (Score:4, Interesting)
They just want to change everything all the fucking time until all the users flock to something less flashy and more productive, and then the KDE devs will be free to play Starcraft all day long.
So why haven't you moved to something less flashy and more productive? I certainly have and I suspect a large number of others have too. The straws that broke this camel's back were the ridiculous weight of the "semantic desktop" and the seemingly endless supply of visual fluff that adds nothing to utility.
Re:What about Qt? (Score:2, Interesting)
The thing I'd worry about here is not so much bloating Qt as diminishing Qt's code quality. Qt's code base is one of the best C++ libraries I've seen. Whether you're a fan of KDE or not, I hope you will admit that it's a bit arcane. Cause and effect are often difficult to connect, and complexity is rampant. Whenever I've tried to debug KDE apps, I've felt like the learning curve was more of a wall. It would be a shame to take something clean like Qt and push KDE into it wholesale.
Now, if it were possible to take KDE as a feature spec, rather than a code base, and carefully add features to Qt so that those features could be removed from KDE, while still maintaining the high level of quality in the Qt library, *that* might be worth doing.
Easy for a company to make a legal mess? (Score:4, Interesting)
"Can I switch from using Qt under the LGPL to commercial afterwards?
"No. Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL-licensed version of Qt and then transitioning to a commercial version of Qt."
Four sections earlier, the FAQ says this, in part:
"... If you are uncertain as to whether or not you will be able to comply with the LGPL requirements at the time you begin your development, our recommendation is that you purchase a commercial license as it gives you the flexibility to decide licensing (commercial or LGPL) at the time of distribution."
It seems to me that it would be easy for a company to create a legal mess for itself. What a company will do in the future cannot be foreseen.
What would happen if a developer at a company who did not have a commercial license, but was using a free license, contributed to a commercial project? Often there are discussions about architecture, and someone may contribute ideas for an architecture that are later adopted. The sociology of programming is not as clean as Qt licensing apparently considers it to be.
Note that this problem was not created by Nokia. It existed when Qt was owned by Trolltech.
Re:Quanta? (Score:4, Interesting)
I have: XFCE. I still use Kate and kio though. A few times a day, I have to run a few killalls to reap zombie kio processes, but at least the WM doesn't get in my way anymore.
Comment removed (Score:3, Interesting)
Qt helps stability (Score:1, Interesting)
Keep the specifications as they are. Fix all the current issues and make a SOLID product. It's good, but could be a LOT more stable and tight. When that's done, then go for the big merge and add new features.
one of the reasons KDE apps go down in flames with segfaults is KDElibs' memory management. Qt can remove the memory cleanup work with it's garbage collection. However, it's still possible to manually destroy things, so it's not mandatory. Make it work and then make it efficient.
the root of evil code is premature optimization.