Frameworks/Epics/Splitting kdelibs

From KDE Community Wiki

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
  • All Find*.cmake modules audited and upstreams to cmake or ecm as appropriate
  • Follows the policy on directory organization
  • Unit tested
  • Has an appointed maintainer
  • Maintains source compatibility over kdelibs
  • Split into its own git module; pre-existing history will remain in the kdelibs repository and be accessible with git graft
Status Framework Tier Type Maintainer Comment
DONE itemmodels Tier 1 Functional Stephen Kelly
IN PROGRESS libkauth Tier 1 Integration Dario Freddi
  • Not following directory organization yet
  • Unit tests?
IN PROGRESS libkdbusaddons Tier1 Functional Kevin Ottens ooh.. found http://community.kde.org/KDE_Core/QtMerge

idletime is a framework, not a tier ;)

  • Not following directory organization yet
  • Wrongly named libkdbus
IN PROGRESS libkplotting Tier 1 Functional ?? Maintainer missing
IN PROGRESS solid Tier 1 Integration Alex Fiestas

Not following directory organization yet

IN PROGRESS threadweaver Tier 1 Functional ??
  • Not following directory organization yet
  • Maintainer missing
IN PROGRESS sonnet Tier 2 Functional ??
  • Not following directory organization yet
  • Maintainer missing
IN PROGRESS libkarchive Tier 1 Functional Mario Bensi
  • Depends on KSaveFile
  • Depends on KMimeType
IN PROGRESS libkcoreaddons Tier 1 Functional Romain Perier
  • Not following directory organization yet
  • Unit tests?
  • Why is it still in staging?
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

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 1
    • kguiaddons (Tier 1 / Functional)
    • idletime (Tier 1 / Integration)
    • kjs (Tier 1 / Functional)
  • Tier 2
    • libkconfig (Tier 2 / Functional) Details on KConfig/DConf, etc.
    • libkconfiggui (Tier 2 / Functional)
    • window management (Tier 2 / Integration)
    • color widgets (Tier 2 / Functional)
    • job widgets (Tier 2 / Functional)
    • widgets (Tier 2 / Functional)
  • Tier 3
    • libkservice (Tier 3 / Solution)
    • libkdebug (Tier 3 / Functional)
    • itemviews (Tier 3 / Functional)
    • XMLGUI (Tier 3 / Functional)
    • dialogs (Tier 3 / Functional)
    • emoticons (Tier 3)
  • Unknown Tier
    • kbookmarks
    • kio-core
    • kio-widgets
    • plasma
  • Tier 4
    • kcmutils (Tier4)
    • kde consistency framework (Tier 4)
    • kparts (Tier 4)
    • kde4support (Tier 4)

And probably more...

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.

Retrieved from "https://community.kde.org/index.php?title=Frameworks/Epics/Splitting_kdelibs&oldid=16515"