KDE Core/Platform 11
- 1 Insert logo here
- 2 Purpose of the Sprint
- 3 Topics
- 3.1 KDE at Qt 5
- 3.2 KDE in OpenGov
- 3.3 Workflow / Management
- 3.4 Modularization of KDE libraries
- 3.5 Framework vs Platform
- 3.6 Redundancies
- 3.7 Moving stuff into kdelibs
- 3.8 Separation of KDE libraries and platform
- 3.9 A service framework
- 3.10 Is KSyCoCa needed anymore?
- 3.11 Library use of KStandardDirs
- 3.12 Who will do the work?
- 3.13 Build Profiles
- 3.14 Build system
- 3.15 KDE from downstream
- 4 Logistics
Insert logo here
making it now (Nuno)
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.)
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
- refcounted quit in QCoreApplication
Framework vs Platform
- Qt OpenGov
- Policy towards QtMobility
- 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?
- 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?
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?
June 1/2 - 6/7
Travel and Accommodations
See at the general Randa page.
Food, Drink and Shopping
See at the general Randa page.