KDE Core/Platform 11: Difference between revisions

From KDE Community Wiki
(Undo vandalism by Kpzeta (talk))
Tags: Replaced Undo
 
(86 intermediate revisions by 32 users not shown)
Line 1: Line 1:
{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
== Insert logo here ==
making it now (Nuno)
[[File:Coreproposal.png]]
[[User:Saleel]]'s Proposal. SVG:[[Media:Coreproposal.svg]]
== Purpose of the Sprint ==
== 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.
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.)
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.)


== Participants ==


This sprint will aim to bring together developers who contribute to the KDE Platform directly, who use it in sophisticated applications, packagers of it and those involved in setting similar policies for Qt.


The proposed break down of attendees:
== Topics ==
 


* 12-15 kdelibs and kdebase-runtime commiters
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.
* 3-5 KDE application developers
* 2-3 packagers
* 1-2 people from the KDE Release Team
* 1-2 Qt representatives


making for a total of 19-27 people.
=== KDE at Qt 5 ===


If you would like to attend, please record your name below. Date organization will occur at a later point.
* How does KDE view the Qt5 transition?
* Will there be further Qt 4 feature releases possible through OpenGov?


{| class="wikitable" border="1"
=== KDE in OpenGov ===
!Name
!Email
!Role / Work
!Arrival
!Depart
!Est. Cost
!Need Sponsor?
!Need Hotel?
!Food Req.
!Airport
!Flights
|-
|Aaron Seigo
|Meeting facilitation, libplasma
|
|
|
|yes
|yes
|vegetarian
|
|
|-
|John Layt
|KLocale & co
|
|
|
|yes
|yes
|
|
|
|-
|Marijn Kruisselbrink
|kdelibs mobile, meego packaging, koffice
|
|
|
|yes
|yes
|vegetarian
|
|
|-
|Jeremy Whiting
|knewstuff, accessibility
|
|
|
|yes
|yes
|any
|
|
|-
|Thiago Macieira
|Qt, used to work in kdelibs
|
|
|
|no
|no
|any
|
|
|-
|Andreas Hartmetz
|kdelibs - mostly KIO and some kdeui
|
|
|
|yes
|yes
|yes
|
|
|-
|Kevin Ottens
|KDE Platform+Frameworks modularity, interaction with Qt
|
|
|
|yes
|yes
|no seafood
|
|
|-
|David Faure
|kdelibs, interaction with Qt
|
|
|
|no
|yes
|
|MRS/LYS
|
|-
|Artur Souza
|KDE UI/Core + QML/JS
|
|
|
|yes
|yes
|any
|
|
|-
|Dario Freddi
|Authorization Framework, Solid, Possibly all things KCM*
|
|
|
|yes
|yes
|any
|LIN/BGY/MXP
|
|-
|Alexander Neundorf
|buildsystem (kdesupport +kdelibs +kdepimlibs +kdebaselibs) modularization
|
|
|
|yes
|yes
|any
|
|
|-
|Raphael Kubo da Costa
|Mostly kdecore and kio. KDE/Qt on FreeBSD.
|
|
|
|yes
|yes
|any
|
|
|-
|George Kiagiadakis
|drkonqi, small contributions to kdelibs, debian packaging
|
|
|
|yes
|yes
|any
|
|
|}


== Topics ==
* 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


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.
=== Packaging ===
* Split git modules -> split tarballs?
** If so, split schedule?
* Should we provide artificial monolithic tarballs?


=== Modularization of KDE libraries ===
=== Modularization of KDE libraries ===


Alex: should IMO include not only kdelibs, but also kdesupport, kdepimlibs and kdebase libs
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 ===
=== 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 ===
=== Redundancies ===
KLocale & co vs QLocale & co: How to act local everywhere while retaining configurability.
* 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 Profiles ===
=== Build Profiles ===
Line 209: Line 105:
=== 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.
** 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 ===
=== QML and Javascript ===
=== Class-level Analysis of KDE Libs ===
Spreadsheet: https://spreadsheets.google.com/spreadsheet/ccc?key=0AhQ1BhQL6D9wdGpvOHN0N0xRZVBGU1c3ZmdiaXZORUE&hl=en_US&authkey=CKTcjdgP
KDE Runtime: https://spreadsheets.google.com/spreadsheet/ccc?key=0Am2uzNh0KAtpdFVaRkMtMXZEcC00MEE0dzhrbWV2Nnc&hl=en_US&authkey=CI_3zNMC
== Work Groups ==
{{warning|These pages contain rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
* [[/Eliminating Duplication With Qt|Eliminating Duplication With Qt]]
* [[/KDEQtRelationship|KDE and Qt relationships]]
* [[/PlatformVsFrameworks|Platform vs Frameworks]]
* [[/kdelibsDependencies|Splitting KDELIBS]]
* [[/Developer Story|Developer Story]]
* [[/Settings|Settings: KConfig, DConf, QSettings]]
* [[/Buildsystem|Buildsystem, Packaging]]
** [[/Buildsystem/FindFilesSurvey|Find* files survey]]
* [[/Geolocation|Geolocation Services]]
* [[/Git Workflow|Git Workflow]]
* [[/FrameworksQA|Frameworks QA]]
* [[/DownstreamConsiderations|Downstream Considerations]]
* [[/QCS_Planning|Qt Contributor Summit planning]]
* [[/QtLibraryCollection|Collection of Qt libraries service]]
* [[/openIssues|Open issues left on Kanban]]


== Logistics ==
== Logistics ==
Line 218: Line 158:
=== Dates ===
=== Dates ===


One week sometime in March-May 2011?
June 1/2 - 6/7
 
T.B.D.


=== Location ===
=== Location ===


T.B.D.
[http://community.kde.org/Sprints/Randa Randa], Switzerland


=== Travel and Accommodations ===
=== Travel and Accommodations ===
See at the general [http://community.kde.org/Sprints/Randa Randa] page.


=== Food, Drink and Shopping ===
=== Food, Drink and Shopping ===
See at the general [http://community.kde.org/Sprints/Randa Randa] page.

Latest revision as of 04:00, 27 June 2023

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


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

Class-level Analysis of KDE Libs

Spreadsheet: https://spreadsheets.google.com/spreadsheet/ccc?key=0AhQ1BhQL6D9wdGpvOHN0N0xRZVBGU1c3ZmdiaXZORUE&hl=en_US&authkey=CKTcjdgP

KDE Runtime: https://spreadsheets.google.com/spreadsheet/ccc?key=0Am2uzNh0KAtpdFVaRkMtMXZEcC00MEE0dzhrbWV2Nnc&hl=en_US&authkey=CI_3zNMC

Work Groups

Warning

These pages contain rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


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=96968"