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...
No! No! No! I enjoy having Qt free from other stuff! It's big enough already! If you want, just make a system better of find a way to communicate better, but DO NOT FUCK MY PRECIOUS Qt!
I'll fork it if I have too!
Have you heard about SoylentNews?
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.
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.
Live today, because you never know what tomorrow brings
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
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.
Basically, there's three phases of software:
1. Software that's in development. Sure, there's bad decisions made, but at least things are changing. After a decade of neglect, Windows seems to be back in development mode. KDE is definitely in development mode. Developers love this, because nothing has to be "finished" or "bug free." Everything can be a quickly hacked-together proof of concept.
2. Software that's in support mode. Almost nothing happens, except for a few patches. Mac OS X seems to be in support mode these days, same with Gnome. Support mode is actually a good thing for users who are used to the product, but developers will get bored.
3. Software that's dead. No patches, the developers abandoned the project. Eventually the users will disappear as well.
There's no -1 for "I don't get it."
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.
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.
Live today, because you never know what tomorrow brings
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
You got that completely wrong. The reason there's Gnome stuff in Meego and not KDE stuff is because Meego is a merge of 2 older distributions that used Gnome stuff by default. They only added Qt because Nokia bought it in the mean time.
Mada mada dane.
Stop spreading lies. Nokia takes lots of KDE to MeeGo and helps KDE a lot. KDE also uses GLib in many places.
MeeGo IVI is not based on Clutter. It uses Qt. See http://meego.gitorious.com/meego-ivi-ux/ivihome/blobs/master/launcher.cpp
MeeGo Netbook uses Clutter because it's just the continuation of the older Moblin GUI which was based on Clutter and Intel found it pointless to rewrite it.
Nokia is probably the biggest (at least one of the biggest) corporate sponsor of KDE -- for example Aaron Seigo in employed by Nokia just to work on KDE. Nokia brought KOffice to Maemo/MeeGo, sponsoring a smartphone GUI, improve file format converters, etc.
MeeGo Handset will also use KCal for example.
Nobody at KDE is getting desperate. The "merger" is just an idea by a single guy and nothing KDE as a whole is actively pursuing. Considering how many of KDE are against that idea, I don't see how it could become reality.
KDE is one of the healthiest FOSS projects of all. According to Wikipedia KDE is the 2nd largest FOSS project after the Linux kernel.
KDE has no reason to be desperate. Even if MeeGo was only using Qt and no KDE code at all, GNOME still got the boot while a KDE-related technology (Qt) got in. Some back-end services remain but everything related to GUIs was deprecated. Even MeeGo Netbook uses "Mx" as its toolkit, not GTK (though some applications still use GTK). And now GNOME is in the middle of the Shell vs. Unity battle with the weird result that now even Canonical is a bigger contributor to KDE than GNOME even though their "GNOME distribution" is the premier one.
No, KDE is healthy and not at all desperate.
(PS: My post may seem anti-GNOME but it's not meant that way. GNOME is a large community that will survive current events and probably become even stronger after their platform was renovated with their 3.0 release.)
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.
What's actually wrong with Gnome?
I love it. It's not changed massively in the last few years, true, but I don't really get why it should. It works, it looks fine, it's pretty responsive and light enough for general use....
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.
This is a quote from the Qt licensing FAQ:
"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.
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
Why do so many programmers are still unaware of Bash's string-parsing built-in capabilities,
and prefer to use the 'basename' command instead?
For the above renaming one would suffice to type:
mv $f ${f%.*}.jpg
See: http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameter-Expansion
Why do so many programmers are still unaware of Bash's string-parsing built-in capabilities,
and prefer to use the 'basename' command instead?
Why do so many 2nd generation Linux users presume that everyone uses bash?
Keep script snippets bourne shell and POSIX compatible, especially when posted to the public, so anyone can copy/paste them into the shell they use. Even if they use bash.
For this example, it's far from unthinkable that it would be run on a mediacenter appliance, most of which don't have bash (embedded tends to use busybox), but do have ImageMagick.
Out of curiosity, why didn't sikuli and gnee work for you?
Change is certain; progress is not obligatory.