KF6 meeting notes 2022-01-11

[Volker Krause]

https://invent.kde.org/frameworks/kio/-/merge_requests/700
- ship it, can be used everywhere

https://invent.kde.org/frameworks/kservice/-/merge_requests/79
- can we do this now in all frameworks, or wait one KF release for fallout?
- can be done now for all frameworks

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/223
- alternative: https://invent.kde.org/frameworks/extra-cmake-modules/-/
merge_requests/222
- responsible for the majority of unit test failures on the CI
- background: https://bugreports.qt.io/browse/QTBUG-86173

https://invent.kde.org/frameworks/kdeclarative/-/tree/master/src/qmlcontrols/
kquickcontrolsaddons
- is all of this still in use/needed, particularly looking at PlotData/
Plotter?
- the plotter is replaced by kquickcharts, so that can go entirely
- there's an existing MR for this, but there's an uncertainty on how to 
deprecate QML components
- https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/36

Porting to Qt shader tools:
- needs updates to shader code (not sharable with 5)
- needs CMake code for integrating with Qt shader tools
- Nico has tried that on a different project
- use kquickcharts as an early branched pilot port

Plasma 6 timeline
- due to LTS requirements Plasma 6 branching is only possible in 18-24 months
- see also https://mail.kde.org/pipermail/plasma-devel/2022-January/
121500.html
- a lot of work is probably possible in the 5 codebase, following the approach 
of Frameworks
- we need to get a better overview of Qt6/KF6 porting work, and Plasma 6 
specific changes, to estimate the work
- doing KF6 in-place porting in the Plasma 5 codebase is ok where feasible, 
following the same approach as Frameworks
- look into QML forward compatibility API
- there are Qt6 apps already, so we need the Qt6 platform integration bits 
sooner rather than later anyway - releasing those ahead of a full Plasma 6 is 
a possibility if needed
- if we want to have components change sides between Frameworks and Plasma, 
that can be done for the 6 transition and should be decided well ahead of that 
(see also the discussion on that at Akademy).
- Plasma Framework might rejoin KF6 later, so it can be refactored/reworked as 
part of the Plasma 6 work and is not blocking KF6

https://phabricator.kde.org/T12142
- mainly a communication issue to explain what is supported/not supported 
outside of Plasma/Linux.
- platform-only code that needs ifdefing vs stub implementation on all 
platform
- kactivities is rather a Plasma-specific implementation rather than a 
platform abstraction

https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/
48#note_375267 (https://phabricator.kde.org/T13924 )
- Should the *Private classes be declared outside of the namespaces? KRunner 
has them declared inside of the namespace.
- putting the private classes into the same namespace is the usual way used 
elsewhere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20220111/07ca7544/attachment.sig>