KDE Core/Platform 11

From KDE Community Wiki

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 - If Qt5 moves QLocation and QAddress from QtLocation to QtCore as data transfer classesmost issues would be solved in KDE5.

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

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.

Retrieved from "https://community.kde.org/index.php?title=KDE_Core/Platform_11&oldid=12491"