Slashdot Mirror
KDE Developers Discuss Merging Libraries With Qt
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?"
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
Why don't we finish some unfinished projects (Quanta) that many people are waiting for before changing things again.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I'm sure it would be convenient for the KDE folks, but wouldn't this be a little superfluous for everyone using Qt on non-KDE platforms? Qt is a pretty massive runtime as-is...piling in the KDE libraries seems to me like it would be adding a lot of weight for relatively little benefit to anyone other than KDE. I don't use KDE myself, but I have been developing for Qt for a while...anyone who knows more about the KDE libs feel free to correct me if there's actually some great benefit I'd yield from having the KDE libs included in Qt...
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.
Being unpolitical
means being political
without realizing it.
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!
STOP . AMERICA . NOW
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.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Qt is working on modularizing itself. So you could just not compile the bits you don't want.
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.
It seams that you don't have a clue of what you're talking about.
How about they fix the steaming bloat-fest that is KDE4 before thinking about KDE5?
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Qt is on LGPL for some time now. What you wrote was true few years backwards.
http://qt.nokia.com/about/licensing/
its 2010 no normal user should ever have to touch a CLI.
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.
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.
Actually, they keep messing with OS X. 10.6 just saw few user-facing changes; most of the new stuff was only of interest to developers. Of course Apple has announced virtually nothing new for 10.7 but then again that's SOP for them until shortly before the launch. I expect new features to be announced later.
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.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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.
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.
I'm not a lawyer, but I play one on the Internet. Blog
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.
-- Let's go Viridian.
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