Guest post by According to a recent article on dot.kde.org, work is proceeding well on the modularization of KDElibs. Instead of being one large static library, KDElibs is being divided into a multi-tiered module system that consists of three framework categories.
These modules will be able to be used by any Qt application without the need to pull in unneeded code as was often the case with version 4 of KDElibs. This change from one large library to a set of smaller but interlinked modules has necessitated a name change from KDE Platform to KDE Frameworks for this aspect of the larger KDE Project.
From the article:
The Frameworks can be divided into three categories:
Functional elements have no runtime dependencies. For example, KArchive handles compression and decompression for many archive formats transparently and can be used as a drop-in library.
Integration designates code that requires runtime dependencies for integration depending on what the OS or platform offers. For example, Solid supplies information on available hardware features and may require runtime components to deliver some of the data on some platforms.
Solutions have mandatory runtime dependencies. For example, KIO (KDE Input/Output) offers a network-transparent virtual filesystem that lets users browse and edit files as if they were local, no matter where they are physically stored. And KIO requires kioslave daemons to function.
Modules may be written in such a way that they require only limited tiers of dependency chains. This should allow Qt application creators to use only the aspects of KDE that they find useful for their application. This modularization will allow for leaner, cleaner code and opens KDE technology to many more platforms than was previously practical; especially in the embedded and mobile markets.
If you would like to know more about the work on KDE Frameworks 5 the KDE.org article offers many useful links; including work with upstream, a roadmap, and current progress.
This is certainly moving in the right direction. I’m glad to see it progressing well, and look forward to the results.
As a Qt developer I’m looking forward to using some of these modules.
I think you can already, I often go to KDE code for things i certainly do not want to code, like kselectionproxymodel.h or so.
There are many bits that are only Qt dependent so you can use it without enormous effort.
“Instead of being one large static library, KDElibs is being divided”
If it is a large static library then it is surely, by definition, compiled into each executeable which is potentially hideously wasteful on memory.
If they actually meant shared library then I am unsure of the scale of benefit of dividing it down into multiple smaller shared libraries.
Perhaps in the modern style where one o/s runs on everything from your wristwatch to your mainframe then perhaps it makes sense to those familiar with the detail.
“If they actually meant shared library then I am unsure of the scale of benefit of dividing it down into multiple smaller shared libraries.”
The benefits are that if I write an app, I can use some kde functionality without having to have the one large library as a dependency, and instead only depend a selection of the smaller libraries. Also at runtime, only the smaller libraries I used will be loaded into memory, and not the one giant library with everything. It’s also about keeping the code-base clean and maintainable.
Even though these can be true on theory, in practical cases at runtime when you are a KDE user, most of the libraries will be already cached.
I totally agree with the other points and add that code refactoring usually presents a good opportunity to optimize, to better isolate and improve code interface/contracts.
But for other platforms the libraries wont be cached already, that’s why this is also very useful for Qt developers in general, not just KDE.
(before all, i ocasionally develop apps using Gtk C/C#/python)
KDE will be like the Gtk framework has ever been … right? or not?
While i think Gtk has always been too much disagregated, it is the way to go. But it needs to be publicited as framework and not a series of libraries in *put your favorite language here*.
Anyway, everybody goes for QT these days … what does QT missed that needs to be added? And how it compares with the Gtk environment: gtk (toolkit,widgets and dialogs), glib (low level), gdk, pango (text), cairo/clutter (drawing), multimedia, resources management, etc?
https://developer.gnome.org/
Edited 2013-10-03 14:08 UTC
KDE lost me when they ditched their fast, simple menus for the mess of version 4’s initial design years ago. I wish them well but don’t bother to follow what they do anymore. Best of luck to them, they are a hard-working and talented group of people.
Perhaps you don’t really want to try it anymore but KDE has a classical menu that is two clicks away and is what I use. I really don’t like the new menu but KDE is way more than that.
May you want to give it another try, first right click on the menu icon and unlock the widgets, right click again and chose the classical menu. Done. It has also the best menu editor I know.
I am using the latest release, 4.11.2 on openSUSE and frankly, there is no better DE outside (on my opinion, of course).
Ooh nice. I didn’t know it could do that!
Every time there is an article about KDE, someone has to point out that KDE is irrelevant due to the 4.0 release. 4.0 was released 5 years ago, can we just let it pass already?