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
signature.asc
Description: This is a digitally signed message part.
