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.

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.

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