Intended organization of KDE Frameworks

[Kevin Ottens]

Hello lists,

<disclaimer>
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.
</disclaimer>

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 
graph:
http://files.kde.org/ervin/platform11/kde-frameworks-matrix.pdf

== 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:
http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf

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


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

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110607/7e1a3f2b/attachment.sig>