Ambition. Too little, and you stagnate. Too much, and you end up stumbling. Keep this in mind. KDE4 was, and is, a very brave and ambitious effort, and while in my personal opinion they’ve still got a long way to go, especially in the performance department (I regained some hope lately), they’re getting there. Imagine my surprise that after the recently announced overhaul of Plasma, a rather wild idea has popped up that would mean Qt5 and KDE5 – assuming the idea gets enough support, of course.
The ambitious plan comes from Cornelius Schumacher, and was brought to my attention by the boys and girls over at Phoronix. The mandatory background here is that while KDE is built on top of the Qt framework, there’s a lot of functionality the KDE platform delivers that isn’t in Qt. This leads to the situation where developers have to choose: am I going to write a KDE application, or a Qt application?
The discussion got rolling when Chani asked – Why kdelibs? “When I was at DevDays, I noticed that while people were very enthusiastic about Qt, I was getting a sort of ‘Qt is all you need’ vibe at times – a fine sentiment for promoting qt, but then, what about kdelibs?” she wondered, “And then I realized: what *about* kdelibs? I had no idea how to tell anyone why they should use the kde platform, what advantages it would bring. Hell, at this point I’m not even sure what’s *in* kdelibs, or what the KDE Platform is.”
So, what exactly are the problems developers are facing when they need to decide between targeting the KDA platform specifically, or Qt as a whole? From what I gather reading the thread (and I’ve read all the posts) one of the bigger issues is that Qt is more portable than the KDE platform, making it pretty much a no-brainer to pick Qt if portability is paramount. Or, as Sven Langkamp puts it, “On Windows kdelibs is more burden than help.”
There are more subtle issues too, as John Layt points out. There’s a lot of overlap between Qt and kdelibs, which makes it hard for developers to choose which particular solution to use on a more modular level – Phonon vs QtMultimedia, Solid vs QtMobility, Akonadi/kdepimlibs vs QtMobility, that sort of thing.
“I’m thinking about this stuff as I’m trying to plan for GeoLocation support in kdelibs. Do we stay in-house and copy bits of Marble into kdelibs, but then cut out the mobile guys who will want to use QtMobility? Or do we use QtMobility and the problems that entails away from the mobile platform?” he ponders, “Or do we write some Phonon-like wrapper that will use whichever is installed, but that’s no better for the mobile guys than any other new API?”
One of the major problems is that kdelibs pulls in a whole boatload of dependencies, and isn’t particularly modularised. As Stephen Kelly puts it, there’s “upside-down-ness in parts of the stack and modules”. This is an area where a lot of improvements can be made.
“Because of interdependence, a developer who wants to use KIMAP must also use KStandardDirs, KComponentData, KGlobal and everything else they come with. It should be possible to use a an IMAP library without depending on the entire ‘integration platform’, so I think of kdelibs as upside-down,” he explains, “Even if communication about the separate KDE Development Platform had reached the Qt developers at DevDays, I don’t know if they would care, because they would want libraries, not a ‘platform’ with all the buy-in baggage that entails.”
So, kdelibs needs to be modularised, so parts of it can be used as Qt modules when needed without pulling in everything from Akonadi to the notes plasmoid (that’s a hyperbole, people, please untwist panties). It’s right around this point in the discussion that Cornelius Schumacher comes in and takes it to the next level – merge Qt and the KDE development platform.
“Let’s put all KDE libraries, support libraries, platform modules into Qt, remove the redundancies in Qt, and polish it into one nice consistent set of APIs, providing both, the wonderful KDE integration, consistency and convenience, as well as the
simplicity and portability of the Qt platform,” he states, “I know what you think (‘madness’, ‘no’, ‘KDE 5’, ‘impossible’, ‘governance’, ‘binary compatibility’, ‘Nokia’, ‘impossible’, …), but if you put that aside for a while and think big, wouldn’t that be a wonderful answer to all the struggles we have with kdelibs?”
He further details that in recent years, development has shifted away from libraries, towards applications, as demonstrated by how difficult it is to do even basic maintenance on the libraries. While there are still “brave souls” taking care of kdelibs, it’s really hard to keep up. It would be much better to turn kdelibs into a set of Qt modules, maintained by the KDE community.
“There are probably a hundred times as many Qt developers out there than KDE developers, and if Nokia is only half-way successful with their plans for Qt, this ratio will continue to change rapidly in favor of Qt,” he goes on to say, “By merging the platforms we could turn all these Qt developers into KDE developers. We could benefit from and contribute to the success of Qt without restrictions. We would reach way more users. We could much more easily acquire contributors.”
As good an idea as this may be, it’s of course not without its downsides and potential pitfalls – quite the contrary. It would require massive changes, nods and help from Nokia and the Qt team, and would most likely lead to Qt5 and KDE5. The idea of developers having to perform massive surgeries on their applications to port them to KDE5/Qt5 so shortly after the long road to Qt4/KDE4 would probably end up as a big disaster. Again.
It’s an interesting idea, and what probably needs to be done anyway is splitting kdelibs up into small and lean modules that technically are Qt modules, but are maintained by KDE, with KDE’s own release schedule and development goals. I personally see no need to ‘hand over’ governance of these modules to the Qt/Nokia community, since Nokia has completely different goals.
There’s two threads about this subject with lots of opinions and details, so, get a cup of coffee or tea, sit back, and get geeky. I’d like some informed opinions in the comments (Aaron, you sometimes read OSNews – anything to add? You’re usually pretty down-to-earth!).
I tend to agree with the paragraph toward the end which suggests kdelibs is broken down into smaller chunks. It sounds like an easier and more reasonable approach at the moment than turning KDE’s base into Qt.
That would be a good first step. As a side effect of that one could clearly start to see what classes are duplicates of Qt classes and start pruning and injecting any additional (non kde) functionality back from K classes to the Qt base classes.
I never quite understood why they didn’t modularize kdelibs4 (further).
Edited 2010-10-31 22:53 UTC
That’d be my assessment too. Globbing things together for no good reason is generally a recipe for headaches. Were it my call I’d say figure out where QT and kdelibs overlap and strip the redundant parts while keeping the unique elements as their own entities for those interested in using them.
I assume with the breaking down into smaller components will also mean removing some of the duplication that exists between Qt and kdelibs. Does it make sense to maintain a separate rendering engine when it would be smarter to hook into the webkit based engine that is already inside Qt? I hope that what eve decision is eventually made it is done on the basis of what is good for KDE rather than particular individuals grandstanding.
Then there is still the issue of a udev/udisk/upower backend; it still isn’t feature complete and a first class backend. Oh well.
Yes! Merge KDE and QT then Merge QT and GTK+. That will solve all of the worlds problems.
Oh that would totally work. If there’s one thing free software users love it’s a lack of choice.
One of the first comments I read on slashdot said they would fork QT if the merge happened.
The cool thing then is that this would provide choice.
You have the choice of reduced duplicated effort. In addition you have the choice of Gtk+ apps working better on KDE and QT apps working better on Gnome.
Also, I don’t care.
That’s a good start, but to be safe you should probably re-implement it in MICROSOFT COBOL and include a binary blob to take care of DRM restrictions that anyone might need to place on a any part of any program remotely if they discover they hold a patent on some part. Free Software lovers will be in heaven!
I want to mod this as funny but I’m not sure if I get the joke.
Well, most lovers of FOSS aren’t too fond of Microsoft +1, nobody really likes cobol +1, nobody likes binary blobs in the midst of otherwise open source ( aka like those that can be loaded into the kernel), nobody likes DRM (information should be free), nobody likes software patents, and of course nobody wants to allow third parties to disable their programs remotely as easily as sending a DCMA takedown notice is now.
That would be the ultimate in lawsuit negotiation, “pay me now or I shut down all of your customers software with one click.” mu ha ha ha …
Considering the possible major stumbling blocks (will Qt want the KDE functionality, will nokia accept the desktop-oriented improvements, etc), it seems like there is a set of large barriers, but if they could be overcome…
Merging Qt and KDE would be AMAZING.
Not only the hugely increased developer support, but the corporate funding, the idea that maybe more user-oriented higher level features will be able to use the EXACT SAME stack on KDE as they do on MeeGo?
I hope this will get KDE’s NEPOMUK implemented more widely.
Also, considering Shuttleworth’s desire to use more Qt, will this mean more mainstream linux KDE apps instead of GTK?
I may be not making sense, or saying things that are not actually applicable, but the idea sounds incredible, if the major barriers can be overcome.
Edited 2010-11-01 00:31 UTC
Merging Qt and KDE would be AMAZING.
Not only the hugely increased developer support, but the corporate funding, the idea that maybe more user-oriented higher level features will be able to use the EXACT SAME stack on KDE as they do on MeeGo?
You’re confusing things. Kdelibs is NOT KDE. KDE is the desktop environment while kdelibs is just a library. KDE consists of a lot more stuff than just a library and thus you could NOT use “exact same stack on KDE as they do on MeeGo.”
*facepalm*
Sorry.
Is NEPOMUK in KDELibs?
Because, if that could be merged into Qt, adopted by Canonical (who are said to be looking at Qt), and Nokia, that would be a wonderful thing.
Tagging file managers are a great idea, and when housing collections of items, folders are not good enough as they mean only one cataloguing method is possible.
Worth noting is that this is also the direction Gnome have been heading in recent years – retiring stuff from the Gnome part of the stack, and replacing them with equivalents lower down in glib and gtk+. For instance, deprecating GConf in favour of a settings API built into glib. Or replacing various widgets in libgnomeui and libsexy with equivalents in core gtk+.
It makes sense to me, anyway. You don’t want to cram everything into the core, but if it does belong there, that’s where it should be. My impression is that there’s stuff in kde-libs that would be useful to those targeting Qt but not KDE, so it would be good to move it higher up. Conversely, there’s plenty of stuff in Qt that could usefully be split out into separate libraries, as proposed last week…
Merge it with meego merge it with boostlibs merge it with llvm merge it with QT merge it with KDE merge it with libreoffice merge it with wine merge it with facebook merge it with osnews merge it with slashdot! merge it with google and yahoo…. MERGE IT ALL!!
Ahem… in light of that though I don’t think merging is bad and hopefully the modules will be buildable separatly from one another merely with less duplication and synergy between projects YAY!
Note: Original quote was “Merge it with Maemo merge it with BoostLibs!!! MUHAHAAHHAAH”
KDElibs provide unified icon set, FreeDesktop standards compatibility. KDE equivalent of registers (KonfigSKeleton), deep dbus requierment and more importantly, Nepokuk and the semantic stack (underused, but with some potential).
Those parts does not make sense on anything but KDE on *nix. The Windows port of DBUS is unusable, the FreeDesktop standard that drive how Linux desktop work are for *nix only and a total duplication of those found on Windows/Mac (don’t misquote me, they can not be replaced by the Windows/Mac ones, they need to be for *nix only) and the semantic stack is worthless if it is not platform wide (for now and for that reason, it is currently useless).
KDElibs can not be merged for those reasons and many other. I am not saying I would not like to see my own apps work on a wider variety of platforms and remove all those #ifdef on those I coded to work with Qt only if needed. But I won’t see a merge coming, because it won’t happen, ever. See how it worked for Phonon, it took a years before it was deprecated. It was based on KDE needs instead of everybody needs.
Sure, there’s stuff that doesn’t make sense. Like KTHML, that would never get accepted since Qt has webkit already. I think the point, though, is that large portions of KDELibs could potentially be merged back into Qt. Then the rest could stay in a much more slimmed down version of KDELibs, or better yet as various Qt modules maintained by KDE.
I don’t know, it sounds like a good move in the long run, but also like something that could take a long time and a lot of effort. Which may not be a wise thing to start so soon after KDE4 is starting to stabilize.
I think they should start working on modularizing KDELibs, that would be nice no matter what the ultimate decision is and will likely be required if they want to merge in smaller chunks at a time into Qt anyway. Then in a couple years when everything is modularized maybe they can take another look and see if it still makes sense.
Yer, cross-platform toolkits exist for a reason, but once you start building your own platform specific environment then you’re already nailing your colours to the mast. You can’t just then roll that environment back into the cross-platform toolkit in an effort to solve problems you think you have.
Put simply, KDE has to make KDE an attractive enough desktop platform so that developers will want to write applications for it and Qt will then want to add better support for it as a platform. That’s the direction things have to go in.
QT is currently be modulised.
And KDE is already break itself down.
This will be a slow transition over the live of KDE 4.x. KHTML usage is slowly being reduced inside KDE and QT Webkit support is being used instead.
Plasma is avoiding duplicating some things up as well.
Yes KDELIBS and QT are merging. This does not need to be rushed. Slow and steedy will be painless.
There is a logical way to get started with this – ensure it’s easy to use a kde module from a plain Qt program without pulling in half the kde. It doesn’t really matter after that whether Qt and kde merge – it’s just a branding issue. Good modular libs could be deployed widely by Nokia next – e.g. it would be possible to have them as internal parts of meego and symbian.
I wholeheartly agree on that.
When writing small programs I use locally — both on Windows and on Linux — I opted for Qt instead of kdelibs, despite that in many areas the later is more easy to use.
Needing so many dependcies would have made it a pain. Having a kdecorelibs that only depended on Qt would have changed that.
This would make kdelibs itself a lot more interesting and sustainable for developers.
Though I think a merge with Qt should not be done in most cases, yeah KUrl should be merged but other parts should just become Qt libs — once their requirements like KUrl have been merged.
I always kind of assumed this was the direction they were heading in with the release of KDE4/QT4. Given Trolltech and then Nokia’s employees always heavy involvement in KDE’s development it just seemed logical. It’s seems that the KDE is disorganized and a concrete direction to a goal like this needs to be stated otherwise KDE4 will just float around forever and stagnate like GNOME2 has.
With the acquisition of QT by Nokia, KDE has been sitting in a potentially explosive position for a couple years now and it seems to continue to be loaded with more powder every day. Currently the largest mobile phone and microchip manufacturers (Nokia and Intel) are unsuccessfully scrambling to create in Meego what KDE almost already is (and so much more). Now Ubuntu, the largest desktop Linux distro, want’s to switch to QT.
If this merger happens it means that every KDE app will be available on Windows and Mac OS’s as well as almost half the worlds mobile phones by default (Amarok could be a potent gateway drug). No opportunity for the adoption of linux by end users of this scale has ever been presented before. It’s been my opinion that the KDE people have been severly neglecting platform promotion.
With some sales savvy and a clear workable proposal I think these three parties could be brought on board to do something really special.
I also think that the KDE4/QT4 Social Semantic Desktop idea is a better fit for a Unity/GNOME Shell type interface than GNOME/Gtk or even KDE’s current one.
To end with a random thought, KDE’s biggest criticism is the KDElibs dependancies on thier apps. I guess people don’t realise that they’re under 15MB in total.
Notice that besides those 15 mb there are a lot of other dependencies. But yeah, most people heavily over-estimate the impact of KDE libs on their system…
You are right in that this is something which should’ve happened a long time ago. The idea isn’t exactly new, at least I know I’ve spoken about this very thing over a year ago with Sebas – Qt just wasn’t very open back then however. Now the time is right to start doing this and I hope it’ll happen.
But there is more than just a communication/promo barrier here – technically it’ll be a lot of work and in some area’s it’ll be impossible with Qt and KDE how they are. So don’t hold your breath. Small steps will have to come first
Whenever more than one person works toward a goal there was sale of the idea preceding it. As a long time salesman I know that people buy the presentation, not the product. This is true about anything you or I have ever done consciously or unconsciously. Our decisons don’t occur spontaniously in our minds but by a series of suggestions. Thats a bit absract but if the sale of this idea can be made KDE/QT can gain major resources for the softwares development. Nobody sets up a factory, starts manufacture and then seeks investment right?
I think KDE would do well as a superset complementing QT be tightly integrated with little overlap but without Nokia on fully board it can’t happen. They must be conviced that KDE is what they need first.
I’d much rather have KDE continue it’s practice of almost traspairent (from a user prespective anyway) of developing KDE4. They’ve done some pretty major changes and since 4.3 it’s been a pretty smooth ride (I probably have the kubuntu team to thank for that).
In my opinion Corny’s atempting this now because he sees that it’s the only way to see KDE/QT live up to it’s potential. I wish him luck.
btw, the 15MB figure was from adding the KDE/Qt specific dep.’s of konqueror together. In total the app weighs in at under 20MB and about 35MB in RAM on my system (unless the evil nspluginviewer goes arwy). It just bugs me to see people badmouth it and happily install bloated ass java and flash with firefox without a word.
Like KTHML, that would never get accepted since Qt has webkit already.
Remember Webkit and Khtml are blood brothers. No new KDE applications are not using Khtml. In fact Khtml is a deprecated API. Legacy support really is the status of Khtml. Correct way is to use the QT webkit for html rendering,
The merge has started. Piece by Piece. While in the process QT and KDELIBS will be converted into modules.
This is not going to be a big jump. By the time the legacy is dropped is most likely a few years off. KDE 4.0 was a big jump and it was required to start this process.
On the issue of dbus for windows. The bugger does truly work. Just it not as fleshed out with dbus services. Sorry to say there are a lot of secuirty things dbus does better.
One thing that I kept thinking while reading this article was that the whole point of KDE is it’s a unified desktop environment. So yes, kdelibs might not be modularised to the extent where you can’t just use one class without importing the whole KDE stack, but then that’s not really an issue given that people using kdelibs should generally be targeting the KDE platform specifically.
Maybe I’m missing the point , but for me the decision between Qt and kdelibs has always been an easy one: am I targeting KDE specifically or not?
That said, I’ve been a happy KDE user since version 2 and haven’t personally experienced any of the performance hits nor instabilities in 4.x (well, 4.2+) that many users have complained about – so I would happily build specifically for that platform should the scenario arise.
I thought they got rid of that marketing approach with the change to new naming (“KDE workspace” or whatever).
I thought the renaming of KDE to KDE Software Compilation was to further emphasise the whole integrated environment aspect of KDE. ie, you don’t just get a DE, but you get toolkits, applications and a whole experience where everything communicates with each other. I guess much like what Apple and MS do with their products on their respective platforms (though perhaps MS less so because they don’t even follow their own GUI guidelines).
In short, I thought what the KDE team was trying to sell (for want a better term) was the whole bundle rather than just a toolkit and/or productivity apps and/or DE shell.
I thought just the opposize – e.g. there is now a separate “KDE development platform”, which sort of suggests you can pick up pieces of the whole KDE instead of dealing with this impermeable monolith that has everything from KIO (useful) to games (not useful).
Well, actually KDE wasn’t renamed to KDE Software Compilation. The SC thingwas meant to be an internal naming to help us define what is the portion that gets syncronously released… unfortunately this got out as the new name, but it isn’t.
The emphasis is instead moving the meaning of KDE from “desktop environment” to “community that writes software” (the acronym doesn’t mean anything now)
and some of the “products” of said community are:
* the KDE Platform (that is, but not only, kdelibs)
* the KDE Plasma Desktop (and netbook, and mobile..) workspaces
* a ton of applications that happens to use the KDE Platform
So, if the said Platform (or parts of it) can have an appeal in the development of applications not directly targeted to one of the KDE Plasma workspaces, but helps the developer anyways (like just happens to have a class that solves their exact problem) everyone wins
This is the kind of issues that end users don’t really care, but i guess it would benefit users.The KDE community is always thinking about what is the next step, and i love that
artsmessage, checkXML, cupsdconf, cupsdoprint, dcop, dcopclient, dcopfind, dcopidl, dcopidl2cpp, dcopidlng, dcopobject, dcopquit, dcopref, dcopserver, dcopserver_shutdown, dcopstart, filesharelist, fileshareset, imagetops, kab2kabc, kaddprinterwizard, kbuildsycoca, kcmshell, kconf_update, kconfig_compiler, kcookiejar, kde-config, kde-menu, kded, kdeinit, kdeinit_shutdown, kdeinit_wrapper, kdesu_stub, kdontchangethehostname, kdostartupconfig, kfile, kfmexec, kgrantpty, khotnewstuff, kinstalltheme, kio_http_cache_cleaner, kio_uiserver, kioexec, kioslave, klauncher, kmailservice, kpac_dhcp_helper, ksendbugmail, kshell, kstartupconfig, ksvgtopng, ktelnetservice, ktradertest, kunittestmodrunner, kwrapper, lnusertemp, make_driver_db_cups, make_driver_db_lpr, makekdewidgets, meinproc, preparetips, and start_kdeinit
Yes folks, it’s the program contained in kdelibs. Why should it be merged with Qt? I don’t get it.
What happened to software simplicity and beauty? they are drowned in developers’ ambitions…
In KDE 3.5. KDE 4.x is quite different.
Yup, although more could probably be shifted to base/runtime:
> rpm -ql kdelibs4 |egrep “bin|libexec”
/usr/bin/checkXML
/usr/bin/kbuildsycoca4
/usr/bin/kcookiejar4
/usr/bin/kded4
/usr/bin/kdeinit4
/usr/bin/kdeinit4_shutdown
/usr/bin/kdeinit4_wrapper
/usr/bin/kjs
/usr/bin/kjscmd
/usr/bin/kross
/usr/bin/kshell4
/usr/bin/kunittestmodrunner
/usr/bin/kwrapper4
/usr/bin/makekdewidgets
/usr/bin/meinproc4_simple
/usr/bin/nepomuk-rcgen
/usr/bin/preparetips
/usr/lib64/kconf_update_bin
/usr/lib64/kde4/libexec
/usr/lib64/kde4/libexec/filesharelist
/usr/lib64/kde4/libexec/fileshareset
/usr/lib64/kde4/libexec/kconf_update
/usr/lib64/kde4/libexec/kdesu_stub
/usr/lib64/kde4/libexec/kio_http_cache_cleaner
/usr/lib64/kde4/libexec/kioslave
/usr/lib64/kde4/libexec/klauncher
/usr/lib64/kde4/libexec/kmailservice
/usr/lib64/kde4/libexec/kpac_dhcp_helper
/usr/lib64/kde4/libexec/ksendbugmail
/usr/lib64/kde4/libexec/ktelnetservice
/usr/lib64/kde4/libexec/lnusertemp
/usr/lib64/kde4/libexec/start_kdeinit
/usr/lib64/kde4/libexec/start_kdeinit_wrapper
The reason for kdelibs is BC and SC. kdebase does not make that promise in general.
So moving things to base would not be a solution.
The only way of getting beauty and simplicity in huge software is breaking it down in a lot of small pieces… Ã la KDE
Lets go threw that list.
kio_http_cache_cleaner Most likely should be deprecated and become part of QT Webkit.
Lot of the printing related would be better of in QT. So cupsdconf, cupsdoprint, make_driver_db_cups, and make_driver_db_lpr. To be correct most of this is already in QT under other names.
checkXML also another item that is inside QT already.
dcop stuff dcop, dcopclient, dcopfind, dcopidl, dcopidl2cpp, dcopidlng, dcopobject, dcopquit, dcopref, dcopserver, dcopserver_shutdown, dcopstart Most likely should be in a lib of its own right. So if dcop ever gets deprecated removal is simple.
What is talked about is not just merging with Qt some merged with Qt some converted into what would be QT module not a KDE designed one. The difference is a QT designed module does not depend on KDE libs instead just on QT itself. Cleanup time.
DCOP is not used in kde4. In case you’re unaware kde4 uses dbus. The original list was from kde3 I believe.
I forgot. Its already legacy for porting KDE 3 applications forward to KDE 4. So if it still in KDELIBS it should be moved out sideways anyhow.
The short answer is “No,” but the long answer is “Yes.”
Pulling the kdelibs monolith apart would be good for everybody (not counting the people who have to do the work) and could only serve to make packaging KDE and its apps easier for distributions.
Once it’s pulled apart if some things could be merged in to Qt, if and where that makes sense, and the result remain source compatible with post-pull pre-merge KDE, then I see no reason not to work toward that kind of code sharing.
Pushing the KDE platform wholesale into Qt, on the other hand, is wrong to the point of stupid.