Forgot your password?
typodupeerror
KDE Linux

KDE Developers Discuss Merging Libraries With Qt 196

Posted by samzenpus
from the merge-ahead dept.
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?"
This discussion has been archived. No new comments can be posted.

KDE Developers Discuss Merging Libraries With Qt

Comments Filter:
  • Focus on the now. (Score:4, Insightful)

    by Tamran (1424955) on Sunday October 31, 2010 @06:26PM (#34083220)

    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

    • 3 phases of software (Score:5, Informative)

      by MrEricSir (398214) on Sunday October 31, 2010 @07:32PM (#34083690) Homepage

      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.

      • by kestasjk (933987) *
        So software in development never has to be finished or bug free, OS X isn't currently being developed, and Windows until recently wasn't being developed.. Fascinating..
      • Re: (Score:3, Insightful)

        by Jesus_666 (702802)
        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
    • Re: (Score:3, Informative)

      by dudpixel (1429789)

      KDE SC 4.5+ is a lot more stable than earlier releases. It was good enough for me to switch back from gnome (I switched to gnome a year or 2 ago due to KDE's instability).

      To all those who think gnome is great and kde is unusable...well, gnome is great, I'll admit that...but with KDE so many apps have tabbed interfaces and for my work that means a lot less windows open and I can group similar tasks together. It makes a world of difference to productivity. Also mulit-monitor support is much nicer - I can

  • Quanta? (Score:4, Insightful)

    by JoeCommodore (567479) <larry@portcommodore.com> on Sunday October 31, 2010 @06:33PM (#34083278) Homepage

    Why don't we finish some unfinished projects (Quanta) that many people are waiting for before changing things again.

    • by La Gris (531858) *

      Good question! I was quite upset by Quanta lagging behind in kde-webdev kde3 and Kubuntu messing further with a kde-webdev kde4 missing quanta and mentioning it in content from the readme. How one can consider Kde seriously with such inconsistencies. By the way, I still enjoy Quanta as it is, despite some of its shortcomings of performance issue when you enter href or load project with thousands of files.

    • Re:Quanta? (Score:4, Insightful)

      by billcopc (196330) <vrillco@yahoo.com> on Sunday October 31, 2010 @08:40PM (#34084214) Homepage

      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:Quanta? (Score:4, Interesting)

        by GumphMaster (772693) on Sunday October 31, 2010 @08:50PM (#34084278)

        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.

        • by cynyr (703126)

          XFCE for the last few years now... before that was IceWM, and before that was GNOME 1 or at least GTK1 based GNOME.

        • Re: (Score:3, Informative)

          by elronxenu (117773)

          I changed to xfce recently after trying KDE 4.x for the 2nd time after 12 months (debian lenny to squeeze). The first time, I backed out of my upgrade. The second time, I took a friend's advice and switched to xfce. It's more stable than KDE (kdm locked up my screen twice in a day), much faster, and things mostly work the way I expect.

        • Re:Quanta? (Score:4, Interesting)

          by billcopc (196330) <vrillco@yahoo.com> on Monday November 01, 2010 @05:05AM (#34086760) Homepage

          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.

    • Re:Quanta? (Score:4, Informative)

      by oiron (697563) on Monday November 01, 2010 @12:06AM (#34085622) Homepage

      You do realise that the guys writing kdelibs aren't the same ones who'll be working on Quanta, right? Quanta should be the domain of the kdevelop/kdewebdev guys, not the kdelibs/kdebase guys.

  • What about Qt? (Score:5, Insightful)

    by bieber (998013) on Sunday October 31, 2010 @06:40PM (#34083330)
    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...
    • Re:What about Qt? (Score:4, Insightful)

      by KugelKurt (908765) on Sunday October 31, 2010 @06:50PM (#34083400)

      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).

      • Quote from the parent comment: '... that can legally only happen if Nokia moves away from the currently mandatory "right to relicense..." '

        Could you explain the "right to relicense" and provide a link? I don't see a reference to that on the Qt web site.

        This paragraph [nokia.com] illustrates two issues with Qt: 1) a possibly impossible licensing provision, and 2) managerial sloppiness. Quoting exactly:

        "You must purchase a Qt Commercial Developer License from us or from one of our authorized resellers before yo
        • Not really, Qt is LGPL licensed and you can switch from GPL to LGPL licensing (according to the FAQs) so the worst case is that you have to follow the LGPL as far as the Qt libraries do.

          As Qt is licensed per developer, they would presumably be covered when working from home as well.

      • by Pseudonym (62607)

        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.

        It would also be extremely inconvenient for the KDE folks to have to make their code work with standard C++. Exception safe KDE will not happen any time soon.

    • Re:What about Qt? (Score:5, Insightful)

      by Carewolf (581105) on Sunday October 31, 2010 @06:51PM (#34083412) Homepage

      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.

      • by gl4ss (559668)

        they should wait for the smoke to clear in qt, so postpone this by 6 months or so.

    • by vbraga (228124)

      It would be nice to have SMOKE and Ruby/Python/... bindings officially supported by Nokia.

      • Re: (Score:3, Informative)

        by kinema (630983)
        If you're interested in using Qt with Python you should take a look at PySide [pyside.org] which is being developed by Nokia.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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

    • I'm not much of a programmer, but as a Debian user I agree whole-heartedly. I use Gnome, and I really don't like the seemingly superfluous K-bloat I get stuck with when installing some packages. If this proposal is adopted, then anything Qt-related will bring in still more unnecessary bloat.

      BTW, this kind of bloat seems to be on the increase throughout Linux.

  • No! (Score:4, Interesting)

    by Jorl17 (1716772) on Sunday October 31, 2010 @06:44PM (#34083360)
    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!
  • by ArneBab (1330439)

    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.

    • by Carewolf (581105) on Sunday October 31, 2010 @06:54PM (#34083430) Homepage

      KDElibs is LGPL and has always been LGPL, common libraries in KDE have always been required to be LGPL so that they could be used by "unfree software" (as you write). Only KDE applications are usually GPL to protect themselves better.

      • by RichiH (749257)

        LGPL != right to relicense.

        Obvious? Yes.

        • by Carewolf (581105)

          Yes, I know that. I didn't adress that part on purpose. That is a political discussion, something that Nokia may or may not decide to change.

  • God no (Score:5, Interesting)

    by Kjella (173770) on Sunday October 31, 2010 @06:48PM (#34083390) Homepage

    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: (Score:3, Informative)

      by Carewolf (581105)

      Phonon is one example. Another brought up in the discussion was QPrinter vs KPrinter, though that has an entirely different background. With QPrinter, KDE was forced to make a suboptimal decision because KPrinter had no maintainer and it seemed unlikely to be even get ported to Qt4, let alone well integrated, before KDE4 was to be released.

  • Oh, hey, look -- (Score:5, Insightful)

    by aussersterne (212916) on Sunday October 31, 2010 @06:55PM (#34083444) Homepage

    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: (Score:3, Insightful)

      by KugelKurt (908765)

      "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.

    • by diegocg (1680514)

      A reorganization wouldn't harm KDE too much. KDE 4.0 wasn't unusable because of the reorganization, but because of the new and unfinished desktop shell. The KDE apps that were ported worked quite well and their interface was pretty much the same.

  • by starseeker (141897) on Sunday October 31, 2010 @07:12PM (#34083550) Homepage

    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.

    • 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

      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 KDE

      • Re: (Score:3, Interesting)

        by Kjella (173770)

        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

  • It depends on which functionality they really want to move to QT. If I understand it correctly they want to move the plasma stuff, which is GUI code, to QT. That makes sense. Just like moving GUI stuff from GNOME to GTK and GDK. However, it makes no sense if they want to move other parts of the application model to QT. It would not hurt, but there would be no benefit.

    • Re: (Score:3, Insightful)

      by abigor (540274)

      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.

  • I don't know about you, but I had a REALLY hard time getting used to running tshark instead of tethereal.

    Can you imagine the havok if we suddenly have KQtDE, KQtonqueror, KQtXSLDbg, KQtBibTeX, KQtSVN, KQtDiff3, KQt9Copy, KQtb3, and so on?

    Madness! Re-tooling this many brains is NOT worth it!!

    • Re: (Score:2, Troll)

      by caluml (551744)
      echo alias tethereal='tshark' >> ~/.bashrc

      There, that wasn't so bad, was it?
  • Not yet... (Score:5, Insightful)

    by Lord Kano (13027) on Sunday October 31, 2010 @08:32PM (#34084152) Homepage Journal

    How about they fix the steaming bloat-fest that is KDE4 before thinking about KDE5?

    LK

    • by segedunum (883035)
      Ahhhh, it's amusing to hear weenies talking about bloat and arguing for software that does less, which is what is behind that word. Sadly, that isn't going to get free desktops competing with Windows and OS X.

      http://www.joelonsoftware.com/articles/fog0000000020.html [joelonsoftware.com]
      • From your link: What is bloatware, exactly? The Jargon File snidely defines it as "software that provides minimal functionality while requiring a disproportionate amount of diskspace and memory.

        No one is arguing for software that does less. People are arguing for efficiency and stability.

There's a whole WORLD in a mud puddle! -- Doug Clifford

Working...