KDE Core/Modularization

KDELibs Rearchitecture

Precondition

KDE applications will stay source compatible. There will be no hard requirement to change anything at the application level. API will maybe be deprecated if needed.

Background

Several directions of Qt development and growth present opportunities to make technology created by the KDE community available to more platforms and to more developers of Qt based applications.

• The advancement of Qt to more and more varied hardware
• The use of Qt as the basis of MeeGo
• The use of Qt as the basis of other platforms in the future
• The use of Qt as the basis of other computer workspaces and interfaces in the future (http://mdzlog.alcor.net/2010/10/20/ubuntu-and-qt/)
• The increased use of Qt in environments such as Industrial Embedded (the machines in your kitchen and house)
• The increased use of Qt in creating Free and NonFree applications on desktop and mobile environments

This availability raises questions for Qt developers in those situations

• What can I use to create a primary widget-based workspace interface for my device? The answer should be libplasma.
• How do I initialize some hardware or software asynchronously and report progress? The answer should be KJob.
• What can I use for asynchronous access to IMAP servers? The answer should be KIMAP and KJob.
• Are there classes available for advanced model-view, or rich text editing? Yes, in Kdeui/itemviews

If GNOME ever switches to Qt, but wants to keep their own platformy bits like configuration format etc, where will they get Qt based libraries to create functionality for their Qt based platform?

The problem

One reason kde libraries are not currently the answer to the issues that Qt developers face is that 'platform parts' of kdelibs are introduced early instead of late in the module. For example the use of kdecore introduces requirements for things like KGlobal, KStandardDirs, KComponentData, KLocale, KConfig. While all useful for a workspace and application suite like KDE provides, none of those should be needed to use an asynchronous job API or itemviews library. Many for many Qt applications, QSettings and QObject::tr are sufficient because the application is deployed by the software vendor with specific hardware in a limited number of languages for example.

The bundling of the functional libraries of kdelibs and the platform integration pieces of kdelibs makes encouraging the use by third parties of the libraries but not the platform (where the KDE platform is irrelevant) difficult, not least from a point of view of communicating it clearly.

Discussion on k-c-d:

• Modularity is not a good thing - it leads to duplication of code and lost features - http://thread.gmane.org/gmane.comp.kde.devel.core/68900
• http://thread.gmane.org/gmane.comp.kde.devel.core/68889
• http://thread.gmane.org/gmane.comp.kde.devel.core/68886
• http://thread.gmane.org/gmane.comp.kde.devel.core/67458
• http://thread.gmane.org/gmane.comp.kde.devel.core/59835

An option

One way of making the functional libraries of KDElibs more easily available is to split the kdelibs module into two modules named KLibs and KPlatform here for clarity. KLibs would be a 3 tier module:

Tier 0: Interfaces.

Some low level modules need access to platform specific data. For example, KLocale uses KStandardDirs to locate gettext translation catalogs. This makes KLocale dependent on the KDE platformy bits. An alternative design is to introduce an interface to get the paths, and implement it trivially on the Qt level, and with KDE integration at the platform level.

The interfaces tier would contain all the interfaces needed (probably few) to access platform specific 'simple types' like strings, urls etc.

It is possible that very pervasive classes in the current KDE4 would need to be in this tier (such as KDateTime), but that would be highly undesirable.

Tier 1: Independent libraries

Libraries such as KJob, KLocale (in theory at least), KItemViews, KConfig etc which can (be made to) exist standalone and depend only whatever dependencies give them their functionality (eg gettext) belong in Tier 1. Tier 1 libraries can not depend on each other, but can use the Tier 0 interfaces. The Tier 1 module is not QtCore only, but individual libraries might be.

Tier 2: Dependent libraries

Libraries such as KIMAP, KMIME, KMBox, libakonadi-kde can have hard dependencies on Tier 1 libraries (such as KJob) and on other Tier 2 libraries (KIMAP can use KMIME). Dependencies on platformy libraries from Tier 1 such as KConfig should be discouraged where using Tier 0 interfaces produces the same effect.

Platforms

KPlatform depends on many but not all of the libraries in the Tiers of KLibs. It implements the interfaces from Tier 0 in terms of the platformy stuff, KConfig, KStandardDirs, KStandardAction etc and contains classes like KComponentData, which all 'applications from the KDE community' use.

KDEinit, KDED, KLauncher, KSyCoCa and DBus are KDE desktop services not necessarily used by KDE applications on other platforms.

It should be possible for an integrator similar to MeeGo, OSX and Windows which defines their own configuration system etc and implement the interfaces to create their own coherent platform and use the functional libraries.

Definitions

With increasing modularity of kde libraries, we can more easily communicate what the benefits are and what is available. Today, kdelibs could be described as 'A platform and set of integrated libraries to support the development of applications written by the KDE community'.

A more modular architecture could be described as 'KLibs, a set of Free Software functional libraries for Qt based applications' and 'KPlatform, an integrated set of libraries for applications written by the KDE community'.

Tasks

Status	Object	Change description	Responsible
TO DO	kdelibs	Split platformy code from functional libraries
TO DO	kdelibs	Merge kdesupport(which is all functional libraries) into kdelibs
TO DO	kdelibs	Remove K-Classes where Q-Classes are available and sufficient
TO DO	kdelibs	Consider refactoring K-Classes where Q-Classes are available but insufficient. Rather than subclasses and wrappers (which other libraries must use, increasing interdependence), it may be possible to redesign to use Builder pattern in some cases. Eg http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKRichTextEdit.html does not really need to be a subclass of QTextEdit.
TO DO	kdelibs	Consider splitting kdecore and kdeui into smaller non-platformy libraries. Additional library loading may be detrimental on some platforms.
TO DO	kdelibs	Consider contributing to Qt parts of kdelibs that are eligable and would be better to have there.
TO DO	kdepimlibs	Merge kdepimlibs non-platformy bits into kdelibs. Be more explicit about dependencies. Eg, KIMAP and libakonadi do not depend on all of kdecore, but mostly just kjob.
TO DO	kdepimlibs	Turn the remaining bits of kdepimlibs into pim platformy stuff only (depending on the kde platformy stuff)