KDE Core/Platform 11: Difference between revisions

From KDE Community Wiki
(add link to class-level dependency graphs for kdelibs modularization)
(→‎Topics: Add some topics.)
Line 17: Line 17:


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.
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 ===
=== Workflow / Management ===
Line 27: Line 37:


* KIO - Split platform and gui parts?
* KIO - Split platform and gui parts?
 
* Initial attempts to create class-level dependency graphs: http://www.kdab.com/~volker/kde/
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 ===
=== Framework vs Platform ===
Line 39: Line 51:
* QDateTime vs KDateTime and KCalendarSystem
* QDateTime vs KDateTime and KCalendarSystem
* KHTML vs QtWebKit
* 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 ===
=== Moving stuff into kdelibs ===


* Move libkonq or parts thereof 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 Profiles ===
Line 48: Line 95:
=== Build system ===
=== Build system ===


What level modularity do we want/need here ?
* What level modularity do we want/need here ?
Chances of CMake becoming the buildsystem for Qt.
* 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?


=== QML and Javascript ===
=== QML and Javascript ===

Revision as of 19:09, 1 June 2011

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
  • 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
    • 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
  • 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.
  • Why does KDE not use USE files?

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.