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

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.