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 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?

Kanban Groups

• [Eliminating Duplication With Qt|Eliminating Duplication With Qt]

Logistics

Dates

June 1/2 - 6/7

Location

Randa, Switzerland

Travel and Accommodations

See at the general Randa page.

Food, Drink and Shopping

See at the general Randa page.