< Frameworks | EpicsRevision as of 13:26, 23 January 2012 by Ervin (talk | contribs) (→February Iteration)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) Contents 1 kdelibs splitting epic 1.1 Important Forewords 2 Existing frameworks 2.1 February Iteration 2.2 March Iteration 2.3 April Iteration 2.4 May Iteration 2.5 June Iteration 3 Backlog 3.1 Finalization tasks 4 Policies 4.1 Strive for Source Compatibility 4.2 Binary compatibility policy relaxed 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 February Iteration Status Framework Tier Type Maintainer Comment DONE itemmodels Tier 1 Functional Stephen Kelly IN PROGRESS kauth Tier 1 Integration Dario Freddi Not following directory organization yet Unit tests? DONE kdbusaddons Tier1 Functional Kevin Ottens IN PROGRESS kplotting Tier 1 Functional Benjamin Port Unit tests IN PROGRESS solid Tier 1 Integration Alex Fiestas Not following directory organization yet IN PROGRESS threadweaver Tier 1 Functional Mirko Boehm Not following directory organization yet IN PROGRESS sonnet Tier 2 Functional Mario Fux Not following directory organization yet IN PROGRESS kcoreaddons Tier 1 Functional Romain Perier Not following directory organization yet Unit tests? Still depends on bits from kdecore (k_global_static, kglobal.h March Iteration Status Framework Tier Type Maintainer Comment TODO kguiaddons Tier 1 Functional ?? Will contain the non-QWidget based classes from kdelibs/kdeui TODO idletime Tier 1 Integration Dario Freddi? Right now in kutils/kidletime TODO window management Tier 2 Integration Martin Graesslin? Right now in kdeui/windowmanagement TODO color widgets Tier 2 Functional ?? Right now in kdeui/colors TODO job widgets Tier 2 Functional Kevin Ottens Right now in kdeui/jobs TODO widgets Tier 2 Functional ?? Right now in kdeui/widgets April Iteration Status Framework Tier Type Maintainer Comment IN PROGRESS karchive Tier 1 Functional Mario Bensi Depends on KSaveFile (see k-f-d for planned solution) TODO kconfig Tier 2 Functional Helio Castro? 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 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 ?? Right now in kio/bookmarks TODO kio-core Tier ? Solution David Faure TODO kio-widgets Tier ? Solution David Faure 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. Retrieved from "https://community.kde.org/index.php?title=Frameworks/Epics/Splitting_kdelibs&oldid=17390" Content is available under Creative Commons License SA 4.0 unless otherwise noted.