< Frameworks | EpicsRevision as of 14:59, 19 September 2013 by Afiestas (talk | contribs)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) Contents 1 kdelibs splitting epic 1.1 Important Forewords 2 Existing frameworks 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 kde4support, kdecore, kdeui, kio, kparts... All unused dependencies are removed Tier1 modules depend only on Qt modules Library name is in CamelCase Modularized CMakeLists.txt [using extra-cmake-modules (ECM)] Installs a Config.cmake file for itself Does not install any Find*.cmake modules itself Calls feature_summary at the end of the toplevel CMakeLists.txt (see kcoreaddons for an example) 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). To make sure of this, do not append to CMAKE_MODULE_PATH, but set it. Does not set EXECUTABLE_OUTPUT_PATH anymore. Follows the policy on directory organization Unit tested Maintains source compatibility over kdelibs Does not use any Q_WS_* defines. Does not include config.h. Does not use QObject::tr() static calls, but only use QCoreApplication::translate(), tr() in a non-static way, or i18n() if the framework depends on ki18n. Document all dependencies in CMakeList between frameworks (example in kauth) Status Framework Tier Type Maintainer Comment DONE itemmodels Tier 1 Functional Stephen Kelly DONE kdbusaddons Tier 1 Functional Kevin Ottens DONE kplotting Tier 1 Functional Benjamin Port DONE solid Tier 1 Integration Alex Fiestas DONE threadweaver Tier 1 Functional Mirko Boehm DONE kauth Tier 2 Integration Dario Freddi DONE kcoreaddons Tier 1 Functional Romain Perier/David Faure DONE kwindowsystem Tier 1 Integration Martin Graesslin DONE karchive Tier 1 Functional Mario Bensi DONE kconfig Tier 1 Functional David Faure Contains KConfigGui + KConfigCore DONE kidletime Tier 1 Integration Dario Freddi IN PROGRESS kservice Tier 3 Solution David Faure in staging, tier 3 because of ki18n, could be tier2 otherwise IN PROGRESS itemviews Tier 2 Functional Aurélien Gâteau Tier 2 because of natural compare (kcoreaddons) otherwise could be Tier 1. Can be moved to stage1 once code is ported to use QCollator DONE kguiaddons Tier 1 Functional Martin Klapetek IN PROGRESS kjobwidgets Tier 2 Functional Kevin Ottens DONE kjs Tier 1 Functional David Faure DONE ki18n Tier 2 Functional Chusslove Illich IN PROGRESS kemoticons Tier 3 Solution David Gil IN PROGRESS xmlgui Tier 3 Integration Àlex Fiestas DONE sonnet Tier 1 Functional Martin Sandsmark Contains SonnetCore + SonnetUi IN PROGRESS frameworkintegration Tier 4 N/A Kevin Ottens IN PROGRESS kio Tier 3 Solution David Faure incomplete, will contain KIOCore + KIOWidgets DONE knotifications Tier 2 Integration Aleix Pol IN PROGRESS kde4support Tier 4 N/A ?? IN PROGRESS kde4attic Tier 4 N/A ?? DONE kcodecs Tier 1 Functional Stephen Kelly DONE kwidgetsaddons Tier 1 Functional Stephen Kelly DONE kcompletion Tier 2 Functional Aleix Pol IN PROGRESS kconfigwidgets Tier ? Functional Aurélien Gâteau DONE kcrash Tier 2 Solution Martin Klapetek DONE kdoctools Tier 2 Solution Aleix Pol IN PROGRESS kiconthemes Tier ? Solution Àlex Fiestas IN PROGRESS kinterprocesswindowing Tier 2 Integration Aurélien Gâteau IN PROGRESS ktextwidgets Tier ? Functional Martin Klapetek DONE kunitconversion Tier 3 Functional Aleix Pol IN PROGRESS kwallet Tier ? Integration Valentin Rusu IN PROGRESS plasma-framework 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 IN PROGRESS kbookmarks Tier ? Functional David Edmundson In staging TODO kcmutils Tier 4 N/A ?? Right now in kutils and kutils/ksettings TODO kprintutils Tier ? ? ?? Right now in kutils TODO kparts Tier ? ? ?? Right now in kparts IN PROGRESS dnssd Tier ? ? Aleix Pol Right now in dnssd TODO kdeclarative Tier ? ? ?? Right now in experimental/kdeclarative TODO kdesu Tier ? ? ?? Right now in kdesu TODO kdewebkit Tier ? ? ?? Right now in kdewebkit TODO khtml Tier ? ? ?? Right now in khtml TODO kssl Tier ? ? ?? Right now in kio/kssl TODO kjsembed Tier ? ? ?? Right now in kjsembed IN PROGRESS knewstuff Tier 3 ? Jeremy Whiting Right now in knewstuff TODO kpty Tier ? ? ?? Right now in kpty TODO kross Tier ? ? ?? Right now in kross 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): ... And probably more... Finalization tasks To be executed to complete the epic when all the frameworks are "done": Make sure it builds and runs against Qt 5.2 final Split into its own git module; pre-existing history will remain in the kdelibs repository and be accessible with git graft Produce a script or cmake file to recreate a kdeexamples tarball out of a set of examples directory in the frameworks 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() / KGlobal::deref() -> QEventLoopLocker 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=34436" Content is available under Creative Commons License SA 4.0 unless otherwise noted.