KDE Core/Platform 11

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
- Changing the way Scripty does its commits so that merging branches is easier
Git documentation
Release tagging

Packaging

Split git modules -> split tarballs?
- If so, split schedule?
Should we provide artificial monolithic tarballs?

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
Policy towards Gnomish dependencies:GCOnf, DConf, GSettings, etc.
Geolocation - If Qt5 moves QGeoCoordinate and QGeoAddress (any others?) from QtLocation to QtCore as data transfer classes most issues would be solved in KDE5 as QtLocation would then be an optional runtime only dependency.

Redundancies

KLocale & co vs QLocale & co: How to act local everywhere while retaining configurability. Do we still need our own locale files?
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. Ditto KLocale. Any others?
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.
- FindFoo.cmake files
Why does KDE not use USE files?
Spread the word about my.cmake.org and have more people submit their logs
Dependency report (add a better description after re-reading http://lists.kde.org/?l=kde-buildsystem&m=130669804027048&w=2)

Upstream and KDE

Should we take Strigi over?

KDE from downstream

How are downstreams like distros affected by these kinds of changes in KDE.
Where can changes in KDE affect distros positively and users positively?

QML and Javascript

Class-level Analysis of KDE Libs

Spreadsheet: https://spreadsheets.google.com/spreadsheet/ccc?key=0AhQ1BhQL6D9wdGpvOHN0N0xRZVBGU1c3ZmdiaXZORUE&hl=en_US&authkey=CKTcjdgP

KDE Runtime: https://spreadsheets.google.com/spreadsheet/ccc?key=0Am2uzNh0KAtpdFVaRkMtMXZEcC00MEE0dzhrbWV2Nnc&hl=en_US&authkey=CI_3zNMC