Frameworks/Epics/Splitting kdelibs

kdelibs splitting epic

Important Forewords

If you are working on splitting a framework, make sure to consult our list of common issues. It will give you an overview of the solutions you're supposed to use to deal with some of the dependencies.

Also, when splitting out a framework, it is part of being done to comply with the KDE Frameworks Policies, it will also need to follow this Epic Policies. Any framework in the staging area cannot move to its final place without following those policies.

And last but not least, if you create a new framework, please consider being its maintainer as well. We need people to ensure the stewardship of all the frameworks.

Existing frameworks

Definition of done:

• No dependency on kdeui or kdecore
• Modularized CMakeLists.txt
• Installs a Config.cmake file for itself
• Does not install any Find*.cmake modules itself
• All Find*.cmake modules needed by the framework and used also by other frameworks have been upstreamed to extra-cmake-modules (via the kde-buildsystem mailing list) or directly to cmake (via the cmake list)
• Follows the policy on directory organization
• Unit tested
• Has an appointed maintainer
• Maintains source compatibility over kdelibs
• Does not use any Q_WS_* defines.
• See Frameworks/Epics/kdelibs_cleanups for more details

February Iteration

Status	Framework	Tier	Type	Maintainer	Comment
DONE	itemmodels	Tier 1	Functional	Stephen Kelly
DONE	kdbusaddons	Tier1	Functional	Kevin Ottens
DONE	kplotting	Tier 1	Functional	Benjamin Port
DONE	solid	Tier 1	Integration	Alex Fiestas
DONE	threadweaver	Tier 1	Functional	Mirko Boehm

March Iteration

Status	Framework	Tier	Type	Maintainer	Comment
IN PROGRESS	kauth	Tier 1	Integration	Dario Freddi	No unit tests, not sure if doable though.
IN PROGRESS	kcoreaddons	Tier 1	Functional	Romain Perier	Still some unit tests to be moved from kdecore Still depends on bits from kdecore (k_global_static, kglobal.h Depends on FAM, but FindFAM is not currently upstream. Decide if it should be in CMake, ECM, or part of kcoreaddons.
IN PROGRESS	kguiaddons	Tier 1	Functional	??	Will contain the non-QWidget based classes from kdelibs/kdeui
IN PROGRESS	window management	Tier 2	Integration	Martin Graesslin	Right now in kdeui/windowmanagement
IN PROGRESS	color widgets	Tier 2	Functional	??	Right now in kdeui/colors
TODO	job widgets	Tier 2	Functional	Kevin Ottens	Right now in kdeui/jobs

April Iteration

Status	Framework	Tier	Type	Maintainer	Comment
IN PROGRESS	karchive	Tier 1	Functional	Mario Bensi	Depends on KSaveFile (see Qt-5.0 page for planned solution)
TODO	idletime	Tier 1	Integration	Dario Freddi	Right now in kutils/kidletime
TODO	kconfig	Tier 2	Functional	Laszlo Papp (Helio Castro mentoring)	Details on KConfig/DConf, etc.
TODO	kconfiggui	Tier 2	Functional	Helio Castro?
TODO	itemviews	Tier 3	Functional	Stephen Kelly?
TODO	dialogs	Tier 3	Functional	??	Right now in kdeui/dialogs
TODO	widgets	Tier 2	Functional	??	Right now in kdeui/widgets

May Iteration

Status	Framework	Tier	Type	Maintainer	Comment
TODO	kservice	Tier 3	Solution	??	Right now in kdecore/services
TODO	XMLGUI	Tier 3	Functional	??	Right now in kdeui/actions and kdeui/xmlgui
TODO	emoticons	Tier 3	Functional	??	Right now in kutils/kemoticons
TODO	kbookmarks	Tier ?	Functional	Julien Desgats	Right now in kio/bookmarks
TODO	kio-core	Tier ?	Solution	David Faure
TODO	kio-widgets	Tier ?	Solution	David Faure
IN PROGRESS	sonnet	Tier 2	Functional	Mario Fux	Dependencies on kdecore

June Iteration

Status	Framework	Tier	Type	Maintainer	Comment
IN PROGRESS	KDE Notifications Frameworks	probably tier2+3+5	Functional or integration	Sune	Work not really started, plan exists in Sune's head Will give a 'low level' collection of notifications Something like KNotification today No knotifydaemon Some gui thing for integration widgets as today
IN PROGRESS	libplasma2	Tier 3	Solution	Aaron Seigo, Marco Martin	libplasma2 already well under way need to identify and break out candidates that belong in lower tiers (e.g. ConfigReader -> kconfigxt++) QGraphicsView and QML libraries Eventually the runtime bits from kde-runtime and the Plasma QML pieces Source compat is priority, but more relaxed than the rest of Frameworks as QML destroys any realistic possibility of that Porting notes Various identified issue/improvements to be made
TODO	kcmutils	Tier 4	N/A	??	Right now in kutils/kcmutils
TODO	kparts	Tier 4	N/A	??	Right now in kparts
IN PROGRESS	kde4support	Tier 4	N/A	David Faure
TODO	kde "consistency"	Tier 4	N/A	??

Backlog

For reference, find the class by class analysis produced during Platform11 on the kdelibs dependencies page

This list is non-final, hence why it is not integrated in the table above, when the scope of a lib gets defined and worked on, it is removed from this list and go in the table above.

Yet to be produced frameworks (foreseen tier and type, not set in stone):

• Tier 3
  • libkdebug (Tier 3 / Functional) / Depends on the results coming from qDebug() in Qt5

And probably more...

Finalization tasks

To be executed to complete the epic when all the frameworks are "done":

• Remove libinqt5
• Port to qt master (likely upcoming 5.1)
• Split into its own git module; pre-existing history will remain in the kdelibs repository and be accessible with git graft

Policies

Strive for Source Compatibility

Avoid removing API from the frameworks branch, even if it is replaced or deprecated. Prefer to implement the old API in terms of the new API.

In some cases this is very easy. For example, many APIs in KGlobal will be replaced as part of the frameworks effort.

• KGlobal::charsets() -> KCharsets::charsets()
• KGlobal::dirs() -> KStandardDirs::global() (or something?)
• KGlobal::ref() -> qApp->ref()
• KGlobal::deref() -> qApp->deref()

etc.

Removing this API from KGlobal is not necessary in most cases, and it introduces a porting burden which is best avoided.

There is unlikely to be a 1:1 mapping of old API to new API in every case, so how to implement the old API may not always be obvious. However, attempting to ensure that the older API remains useful should be at the front of our efforts and standards in the frameworks branch.

Binary compatibility policy relaxed

During the execution of this epic, the binary compatibility contraints from the global policy list is lifted.