KDE Core/Platform 11: Difference between revisions

Revision as of 19:09, 1 June 2011

Insert logo here

making it now (Nuno)

User:Saleel's Proposal. SVG:Media:Coreproposal.svg

Purpose of the Sprint

To examine the current state and near future of the KDE Platform (kdelibs and kdebase-runtime), particularly as it relates to the growing usage of it in new contexts such as mobile or on Windows and MacOS and its traditional usage as a set of conveniences and consistency creators for KDE application development.

The sprint will aim to create an actionable, multi-year roadmap for kdelibs and kdebase-runtime and will examine issues of modularity, topicality and the inherent dichotomy between the KDE Platform as an application development framework (similar to Qt) and as a stand-alone platform to target (similar to, e.g. Windows, MacOS, etc.)

Topics

Note: these are simply sample topics, not final direction on what will actually be discussed. Actual topics will be generated at a pre-sprint meeting online as well as through group authorship of this section.

KDE at Qt 5

How does KDE view the Qt5 transition?
Will there be further Qt 4 feature releases possible through OpenGov?

KDE in OpenGov

How can KDE get more involved in OpenGov?
How can Qt be viewed by KDE people more as part of the stack which can get contributions from KDE people?

Workflow / Management

Recommended Git workflow for kdelibs
Git documentation

Modularization of KDE libraries

Alex: should IMO include not only kdelibs, but also kdesupport, kdepimlibs and kdebase libs

KIO - Split platform and gui parts?
Initial attempts to create class-level dependency graphs: http://www.kdab.com/~volker/kde/
Generally reduce dependency on KGlobal. It causes a lot of interdependency
- K_GLOBAL_STATIC
- refcounted quit in QCoreApplication

Framework vs Platform

Qt OpenGov
Policy towards QtMobility
Geolocation

Redundancies

KLocale & co vs QLocale & co: How to act local everywhere while retaining configurability.
QDateTime vs KDateTime and KCalendarSystem
KHTML vs QtWebKit
Reduce use of KDE APIs in data transfer classes where not needed: KIcon, KUrl (because neither transfer more data than their KDE equivalents, the KDE versions don't need to be in library APIs). Krazy needs to not warn about that.
Investigate what needs to change in Qt for us to be able to use QDateTime as a data transfer class instead of KDateTime. Ditto KAction
It should be easier for 'Qt applications and libraries' to use KDE stuff.

Moving stuff into kdelibs

Move libkonq or parts thereof into kdelibs?

Separation of KDE libraries and platform

Conceptual separation (and possibly stronger, like build/directory system) between functional libraries and platform integrations.
More interfaces are best.
Make it more easy for others to use libraries developed by the KDE community.
Make KDE libraries be something closer to Qt than to the KDE platform.
- Only true dependencies, no interdependencies.
- Possibly more easy to build them separately easier.

A service framework

KDE is becoming more service/multi-process based. Akonadi, Nepomuk, libplasma2 (maybe?).
Some services depend on each other.
All have different mechanisms of being started themselves, and of how they find and start their satellites.
Satellites can be either other processes or plugins in all cases.
There may be opportunities to define some unity among these.

Is KSyCoCa needed anymore?

Not used for mimetypes anymore.
Still used for plugins, but is there still today a need for finding plugins through a database?

Library use of KStandardDirs

Consider defining an interface (maybe in Qt?) for accessing standard directories, which can be used by KDE libraries
In QDesktopServices ?
Abstracting things like that make it easier to use KDE libraries outside of the current existing KDE assumptions.

Who will do the work?

Some desired changes may take a long time/effort.
Can any of it be funded?

Build Profiles

Build system

What level modularity do we want/need here ?
Chances of CMake becoming the buildsystem for Qt.

What can we get upstream to CMake?
- Fix the qt_automoc cmake macro to make the automoc application obsolete.
- The RPath stuff?
- The enable final stuff?
- This stuff should be just as easy for 'Qt only' projects.
Why does KDE not use USE files?

@@ Line 17: / Line 17: @@
 Note: these are simply sample topics, not final direction on what will actually be discussed. Actual topics will be generated at a pre-sprint meeting online as well as through group authorship of this section.
+=== KDE at Qt 5 ===
+* How does KDE view the Qt5 transition?
+* Will there be further Qt 4 feature releases possible through OpenGov?
+=== KDE in OpenGov ===
+* How can KDE get more involved in OpenGov?
+* How can Qt be viewed by KDE people more as part of the stack which can get contributions from KDE people?
 === Workflow / Management ===
@@ Line 27: / Line 37: @@
 * KIO - Split platform and gui parts?
+* Initial attempts to create class-level dependency graphs: http://www.kdab.com/~volker/kde/
-Initial attempts to create class-level dependency graphs: http://www.kdab.com/~volker/kde/
+* Generally reduce dependency on KGlobal. It causes a lot of interdependency
+** K_GLOBAL_STATIC
+** refcounted quit in QCoreApplication
 === Framework vs Platform ===
@@ Line 39: / Line 51: @@
 * QDateTime vs KDateTime and KCalendarSystem
 * KHTML vs QtWebKit
+* Reduce use of KDE APIs in data transfer classes where not needed: KIcon, KUrl (because neither transfer more data than their KDE equivalents, the KDE versions don't need to be in library APIs). Krazy needs to not warn about that.
+* Investigate what needs to change in Qt for us to be able to use QDateTime as a data transfer class instead of KDateTime. Ditto KAction
+* It should be easier for 'Qt applications and libraries' to use KDE stuff.
 === Moving stuff into kdelibs ===
 * Move libkonq or parts thereof into kdelibs?
+=== Separation of KDE libraries and platform ===
+* Conceptual separation (and possibly stronger, like build/directory system) between functional libraries and platform integrations.
+* More interfaces are best.
+* Make it more easy for others to use libraries developed by the KDE community.
+* Make '''KDE libraries''' be something closer to Qt than to the KDE platform.
+** Only true dependencies, no interdependencies.
+** Possibly more easy to build them separately easier.
+=== A service framework ===
+* KDE is becoming more service/multi-process based. Akonadi, Nepomuk, libplasma2 (maybe?).
+* Some services depend on each other.
+* All have different mechanisms of being started themselves, and of how they find and start their satellites.
+* Satellites can be either other processes or plugins in all cases.
+* There may be opportunities to define some unity among these.
+=== Is KSyCoCa needed anymore? ===
+* Not used for mimetypes anymore.
+* Still used for plugins, but is there still today a need for finding plugins through a database?
+=== Library use of KStandardDirs ===
+* Consider defining an interface (maybe in Qt?) for accessing standard directories, which can be used by KDE '''libraries'''
+* In QDesktopServices ?
+* Abstracting things like that make it easier to use KDE libraries outside of the current existing KDE assumptions.
+=== Who will do the work? ===
+* Some desired changes may take a long time/effort.
+* Can any of it be funded?
 === Build Profiles ===
@@ Line 48: / Line 95: @@
 === Build system ===
-What level modularity do we want/need here ?
+* What level modularity do we want/need here ?
-Chances of CMake becoming the buildsystem for Qt.
+* Chances of CMake becoming the buildsystem for Qt.
+* What can we get upstream to CMake?
+** Fix the qt_automoc cmake macro to make the automoc application obsolete.
+** The RPath stuff?
+** The enable final stuff?
+** This stuff should be just as easy for 'Qt only' projects.
+* Why does KDE not use USE files?
 === QML and Javascript ===