Reply to comment

Intended organization of KDE Frameworks

Hello lists,

As, Sebas pointed out we've been meeting here to work on plans to improve our
frameworks offering leading to the decision of leaving the current "kdelibs
model" behind and prepare for a more modular suite named KDE Frameworks. If
you didn't read his email yet, please do so before going back to this email.

Currently, our set of base frameworks is mainly kdesupport, kdelibs and
kdepimlibs. Apart from kdesupport which is now splitted, kdelibs and
kdepimlibs are collections of libraries. That leads to hiding internal
dependencies in those modules, especially in kdelibs, and some of the
libraries are more dumping grounds than proper frameworks with a purpose. The
new model we're moving to will help us have clearer dependencies and push us
toward a more modularized offer. Among other benefits, it will make it easier
for third party developers to use our frameworks, and it should also make
contributions easier.

= Overall organization =
In the new KDE Frameworks organization, we're aiming at sorting our libraries
along two axes. The first axis deals with the runtime dependencies (organized
in Framework Types) while the second axis deals with the link time
dependencies (organized in Tiers). The position of a library along of those
two axis is mainly a stamp or a label we put on a library, it will come with
responsibilities though, and will help us find how to improve a library.

In the following lines, we're going to describe the rules summarized in this
<a href="" title=""></a>

== Framework Types ==
We will have now three Framework Types: Solutions, Qt Addons (OS Integration)
and Qt Addons (Functional). They mainly differ in their runtime dependencies.

* Functional Qt Addons shall not have any runtime dependency (think for
instance of a split libkconfig, it would drag no runtime at all);

* OS Integration Qt Addons can have optional runtime dependencies, if the OS
supports the feature they shall use OS facilities, otherwise a runtime
dependency might be used to implement the feature (think for instance of a
split libkdatetime, it would use ktimezoned on Linux, but on Windows it would
directly use Windows APIs);

* Solutions implement a full technology or stack, including a library and
mandatory runtime dependencies: plugins, servers, etc. (think for instance of
Akonadi, KIO or Soprano).

== Tiers ==
The goal of Tiers is to clarify the link time dependencies of our libraries.

* Tier 1 frameworks depend only on Qt itself and no other Qt based framework;

* Tier 2 frameworks depend only on Qt and Tier 1 frameworks;

* Tier 3 frameworks can depend on any Tier 1, 2 or 3 frameworks.

== Look & Feel + Consistency ==
Obviously the naming of that category is difficult. It will contain all the
frameworks which won't fit in the nice categories described above. The purpose
of those frameworks will be:
* to ensure the behavior and look consistency between KDE Applications;
* to integrate KDE Applications with the Workspaces.

= Examples and Aims =
Maybe after reading through all that, it still seems too abstract, that's
understandable, so in this part of the email we'll cover a partial example of
what our new organization will look like. Keep in mind that it is non
exhaustive, and describes the intended situation rather than the current code
structure. Work will be required to get there.

Throughout this example we will refer to the following graph:
<a href="" title=""></a>

We will quickly present a few examples for some of the ten categories:

* Tier 1, Functional Qt Addon: kcore
libkcore will be a new library adding a few features on top of libQtCore. In
particular, it will contain the job classes, handling of command line
arguments, text handling classes, file locking, and not much more. Because of
that, it will be fairly self contained and will depend only on libQtCore
granting it the Tier 1 and Functional labels.

* Tier 2, Functional Qt Addon: kconfig
libkconfig will be a new library containing our good old KConfig* classes. It
uses QtCore, but also the file locking mechanisms provided by libkcore. It
brings no runtime payload. Because of that, it will be granted the Tier 2 and
Functional labels.

* Tier 2, OS Integration: Window Management
The window management features of kdeui will be split out into their own
library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it
provides integration with the OS which in particular might require a runtime
payload (although not in that particular case), it is granted the OS
Integration label.

* Tier 3, Solution: KIO Widgets
The current libkio will be split in several parts, one containing the core
features, the one we're considering here will contain features like KRun and
the other widgets you might want to use with KIO Jobs. It will depend on
another Tier 3 framework (Services Traders) granting it the Tier 3 label, it
is then allowed to depend on Tier 1 frameworks like solid, or Tier 2 like
kconfig. Also, it is part of a complete stack, including KIO Core and a
runtime payload (klauncher + ioslaves), that's why it is granted the Solution

= Conclusion =
I hope this email will help clarify what we're aiming at with the KDE
Frameworks. We're confident it is a move for a clearer situation regarding the
dependencies of our frameworks. Also, it will hopefully give us a framework
(no pun intended!) to help us identify which ones can be improved and made
easier to use.