Linked by asupcb on Tue 1st Oct 2013 22:37 UTC
KDE

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.

Thread beginning with comment 573772
To read all comments associated with this story, please click here.
Puzzled or muddled!
by ameasures on Wed 2nd Oct 2013 23:17 UTC
ameasures
Member since:
2006-01-09

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

Reply Score: 2

RE: Puzzled or muddled!
by linux-lover on Thu 3rd Oct 2013 00:26 in reply to "Puzzled or muddled!"
linux-lover Member since:
2011-04-25

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

Reply Parent Score: 3

RE[2]: Puzzled or muddled!
by acobar on Thu 3rd Oct 2013 14:22 in reply to "RE: Puzzled or muddled!"
acobar Member since:
2005-11-15

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.

Reply Parent Score: 3