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