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?"
Focus on the now. (Score:4, Insightful)
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.
Tamran
Quanta? (Score:4, Insightful)
Why don't we finish some unfinished projects (Quanta) that many people are waiting for before changing things again.
What about Qt? (Score:5, Insightful)
GPL vs. assignment? (Score:2, Insightful)
I don’t really see how they should be able to merge as long as Nokia requires copyright assignment.
KDE is GPL. Qt is unfree OR LGPL OR GPLv3, as the developer wishes. Qt with KDE could only be GPL.
And I don’t see a reason to deprive free software developers of the advantage which KDE offers them over developers of unfree software.
Re:What about Qt? (Score:4, Insightful)
I'm sure it would be convenient for the KDE folks
If you read the mailing list threads, you'll see that many KDE people don't find that proposal convenient at all because it has the consequences of massive restructuring, different release cycles that don't match SC's, Nokia's currently lacking code submission process, etc.
Maybe and just maybe some select KDE components may end up in Qt but that can legally only happen if Nokia moves away from the currently mandatory "right to relicense" (not the same as copyright assignment but similar in practical terms).
Re:What about Qt? (Score:5, Insightful)
The idea was to merge the parts that would be usefull in Qt, so that answers the questions: Yes, for the parts that makes sense it would be a benefit: Better datetime classes, better config system, asynchronous IO, MIME parsing etc.
It is also obvious that some parts of kdelibs (especially runtime parts, such as ), really wouldn't make sense in Qt anyway.
Oh, hey, look -- (Score:5, Insightful)
KDE considers yet another massive reorganization and new version! Certainly this won't affect usability or the long term future of the project at all, just like the transition from KDE3 to KDE4 didn't!
Re:Oh, hey, look -- (Score:3, Insightful)
"KDE" considers nothing. A few people from within the KDE community play mind games but nothing is an official consideration by the whole KDE community.
Probably a non-starter due to copyright assignment (Score:3, Insightful)
Currently Qt requires copyright assignment (as I understand it) for code to become part of Qt proper. This is going to be a non-starter for a lot of open source folk. As I understand it,this was one of the biggest issues with the OpenOffice.org project in terms of community health, and one of the main drivers for LibreOffice. Qt has gotten away with it better because most of the things people want to do with Qt USE the toolkit instead of CHANGING the toolkit, but it remains a concern. As long as that restriction is in place Qt remains extremely dependent on Nokia continuing development. To date they've done an awesome job - Qt is arguably the best option for cross platform open source graphical application development out there - but longevity for open source is measured (at a minimum) in decades. Corporate good will is thin ice on those time scales - what if Oracle bought Nokia? Could "LibreQt" succeed as a community project without the considerable resources being funneled in by Nokia, if it ever came to that pass? (OK, the other side of this coin is that Qt is ALREADY essential to open source - that concern exists regardless, but it's something to think about in a move like this. Would putting the relevant kdelibs functionality in Qt result in less community familiarity with the code over time?)
Anyway, the KDE devs who wrote the code in question would have to sign on, and to me that sounds like a long shot. The other option - Qt devs implementing Qt versions of features currently in KDE and then KDE moving to the new stuff - sounds slightly more practical but would require a serious manpower commitment.
Re:No! (Score:1, Insightful)
Qt is working on modularizing itself. So you could just not compile the bits you don't want.
Re:KDE4 = Windows Vista (Score:3, Insightful)
You do not know what you are talking about.
First of all, Windows Vista and KDE SC 4.0 has lots of differencies. KDE SC 4.0 was first release of the fourth generation of the KDE Software Compilation (KDE Plasma Desktop, KDE Platform, KDE Applications, KDE Development Platform. Does not include OS, System libraries, application libraries and most of the KDE or Non-KDE Apps) and in other corner, Windows Vista was a software system with NT operating system, Desktop, Application programs, Application libraries, System programs etc.
It is like comparing a motorcycle and bicycle which one is faster!
Secondly, Amarok does not belong to the KDE SC. It does not neither follow the KDE's own release schedule or release numbering. KDE and Amarok developers are two different communities, where Amarok developers just use what KDE developes itself and release in KDE SC.
You should drop down that stupid "KDE 4.0" whining and about Amarok 2.3 whining as well.
KDE idea to mimic a Windows Vista or Windows 7 is as saying that Leonardo Da Vinci was copying a 2000 century modern artists when doing a Mona Lisa painting. Both use(d) paint and canvas and thats it.
Re:Hmm... (Score:1, Insightful)
It seams that you don't have a clue of what you're talking about.
Not yet... (Score:5, Insightful)
How about they fix the steaming bloat-fest that is KDE4 before thinking about KDE5?
LK
Re:Quanta? (Score:4, Insightful)
Because if you've paid any attention to the KDE project since 4.0 betas, you'd have realized they don't give a rat's ass about completeness, performance, stability and usability. 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.
At least that's how it looks like from my perspective, as a developer who has been royally pissed ever since KDE 3.5 was deprecated. I lose gobs of time to bugs and crashes, but am also terrified to update for fear of breakage, as has been the tendency with every minor release of 4.x. I still can't make reliable use of something as fundamental as FTP and SSH kioslaves. You think Quanta's fucked ? I've reverted to a Kate + kioslave workflow and I still run into issues - screw debugging, I can't even tell if my file is going to save properly.
I think the KDE devs need to call for a feature freeze, get what's already in there into a usable and stable condition, long before contemplating superficial topics like merging libs. Necessity trumps vanity.
Re:Qt: Bringing code from home can corrupt a proje (Score:1, Insightful)
Qt is on LGPL for some time now. What you wrote was true few years backwards.
http://qt.nokia.com/about/licensing/
Re:KDE needs some competition. (Score:1, Insightful)
its 2010 no normal user should ever have to touch a CLI.
Re:It depends (Score:3, Insightful)
1. It's Qt, not QT.
2. Qt contains far more than just gui code, and many of the underlying KDE libs would fit in well. I've seen MIME handling mentioned as just one example.
Re:Qt: Bringing code from home can corrupt a proje (Score:2, Insightful)
Qt is on LGPL for some time now. What you wrote was true few years backwards.
http://qt.nokia.com/about/licensing/
It's still true today. You can probably do anything you need to do under the LGPL, but in the event you find some need to have a commercial license, then you still have exactly the same old impossible model. Whoops, we have to rewrite all the code from scratch, since we didn't begin development with a commercial license. Or we can just pretend we started over from scratch, since there's no way to prove anything.
Their commercial licenses are a completely stupid model.
Re:Not yet... (Score:4, Insightful)
There is no "KDE4". What do you mean by "KDE4"? Platform 4(.5)? Plasma Workspaces 4(.5)? The whole Software Compilation 4(.5)?
Uh yeah, that's part of the problem. Enough with the silly names. Did you really not know what he meant?
Re:3 phases of software (Score:3, Insightful)
As with any sufficiently large project, some parts of OS X are in developent mode, some are in support mode and some are only in support mode becuse they aren't quite old enough yet to drop outright. I don't doubt that KDE is similar in that regard.
Re:KDE needs some competition. (Score:3, Insightful)
Using imagemagick: .jpg`.jpeg; done;
for f in *.jpg; do mogrify -profile sRGB.icc $f; mv $f `basename $f
You'll need to supply sRGB.icc, but otherwise it seems to work just fine for me.
GNOME usabilty fixes (Score:3, Insightful)
Instead of a huge change like Gnome Shell, they should (also) be fixing just a few basic usability issues:
-when you select a file in Nautilus and do Ctrl+c or Ctrl+v, they icons should indicated that they've been copied or cut.
-the "Recently Used" in the File Open dialog saves you from a lot of needless folder hopping. But it should also include recently used folders as well (the folder of a file you just saved, plus folders you created recently). "Recently used" should also be present in Nautilus.
-if you choose "single-click" behavior in Nautilus, the File Open dialog should also be single click. OK, so the latter is from GTK-- just add single click to GTK, then have Nautilus set the option for it.
Re:Easy for a company to make a legal mess? (Score:3, Insightful)
That clause was a clear shot at people trying to get away from paying for Qt. Without the clause, one could basically develop commercial applications without paying for Qt licenses, then cough up only when caught, claiming previous development followed the open-source license and "just so happens nobody asked us for the source code".
Trolltech used to depend entirely on revenue coming from Qt licenses, so obviously they wanted to minimize this sort of loopholes.
Re:Not yet... (Score:2, Insightful)
Did you really not know what he meant?
No. What part is supposedly bloated? The applications? Is Marble bloated? Is Gwenview bloated? I don't think so. Therefore the applications part of the SC can't be the problem.
So the Plasma Workspaces. Plasma Desktop is meant to be used similar to classic GUIs like K Desktop Environment 3.5, GNOME 2.x, or Windows. The libraries that serve the foundation are small. libplasma is a mere 3MB in size. Since on top of libplasma KDE produces also a netbook shell as well as a smartphone shell and both run well on those low-performance devices, it can't be the code that's supposedly bloated.
Maybe it's the GUI part of Plasma Desktop? Considering that the supporters of K Desktop Environment 3.5, incl. the people who work on the Trinity project, feel that Plasma Desktop is "dumped down" and offers too few options, that explanation can't be the one either.
That leaves the Platform libraries that are supposedly bloated. As I've written in the previous paragraph, libplasma is small. The rest of the Platform is not put in one giant library. Instead it's split in many small libraries. No KDE application I'm aware of loads everything into memory.
KDE gives application developers a set of Platform libraries to toy with. Nobody is forced to use complete set.
With Qt adopting some of KDE Platform's features (eg. web rendering), app developers are free to switch from the older KDE solution to the pure Qt one. KDE guaranties binary compatibility in kdelibs, so KDE can't just drop them before a Platform 5.0 release.
When you write a KDE application with QtWebKit instead of KHTML, nothing forces KHTML upon you.
It's the same approach GNOME takes since years. If guarantied binary compatibility equals bloat, GNOME 2.x is just as bloated and to get rid of the deprecated parts, GNOME will release 3.0 in spring.
But Lord Kano doesn't mean that because he doesn't want a "KDE5".
As I wrote:
Are KDE Applications bloated? No.
Are the Workspaces bloated? No.
Is the Platform bloated? No.
So what the heck is supposedly bloated? Is Kano's problem that to simplify the release process, all three pillars are released at the same time?
Does he think that to use the Plasma Workspaces one has to install all applications?
KDE releases all individual components at the same time but they remain individual.
He makes a lump-sum statement withaout backing anything up and gets an "Insightful" rating. I merely ask what exactly he means and get "Troll"??? WTF??
At time of writing this, no one, not even you, was able to clarify what he means.
Re:3 phases of software (Score:1, Insightful)
Regarding above phases:
1. developers may like phase 1 until some change in a core library breaks entire application for the n-th time in a row,
not really production-quality environment, wouldn't you agree?
2. "support mode" sounds like "stable, may be used in production" where fixes for security holes and bugs can be made without breaking all applications using it
3. industrial quality, definitely (i'm not joking): cases where software is only used when most bugs have been ironed out and can be deployed to be used for the next 5-15 years
Re:Focus on the now. (Score:3, Insightful)
When you desktop environment requires a RDBMS, you know something is broken.
For what possible reason do they require a true RDBMS rather than something like bdb or even sqlite if you want to get crazy? But frankly, why wouldn't you simply use xml (bottom of the list), flat files, csvs, or some such thing behind a configuration server?
Also, for what reason does one application and/or desktop need to relate to another application and/or desktop? This smells of a classic example of what happens when developers have absolutely no clue what the hell they are doing and needlessly complicate things.
Seriously, why do they need a relational anything?