KF6 meeting notes 2022-01-04

[Ahmad Samir]

On 4/1/22 19:07, Volker Krause wrote:
> https://phabricator.kde.org/T15127 (Qt6 build status update):
> - 60+ modules build
> - Kate (without plugins) with Breeze style and platform file dialogs mostly
> working
> - Kirigami might not be doable without branching (Button.icon,
> QtGraphicalEffects)
> - CI setup in progress
> - in some places includes with the framework prefix don't seem to work anymore
> (ie. <KFramework/KBla> vs <KBla>), any idea where those extra include
> directories came from/got lost?
> 
> https://invent.kde.org/frameworks/kwallet/-/merge_requests/22
> - was launching kwalletmanager via deprecated KService API
> - KIO::ApplicationLaunchJob becomes possible after a QtKeyChain migration of
> KIO > - QProcess as temporary porting scaffolding is an option, but how to ensure
> this doesn't stay around for KF6?
> - make this conditional on KF version < 6.0? needs to fail hard when disabled,
> not silently drop code for the release
> 

Actually on second thought, David F's plan is to move (at least some of) the classes from kiogui to 
KService, that includes ApplicationLauncherJob and CommandLauncherJob, so it can be fixed by using 
those from KService in KF6.

> https://invent.kde.org/frameworks/kio/-/merge_requests/677
> - same solution might be applicable here
> 
> Timeline
> - KF6 branching is not too far away given the current speed
> - so we'll need to discuss whether that already makes sense, or whether there
> are hard KF blockers to sort out first, and whether that's too fast for apps/
> Plasma and we need to help those catch up first
> - full branching vs. only branch some modules
> 
> https://phabricator.kde.org/T14316 - QtKeyChain porting
> - David E found a lot of problems for porting
> - QtKeyChain doesn't support KWallet's concept of two folders - might be a
> problem limited to Plasma/KF users, applications use their own top-level entry
> - use a separator char in the key name for implementing backward compatible
> two-level lookup in KWallet
> 
> https://phabricator.kde.org/T15140
> - "using namespace" in a public header isn't a good idea
> - check if typedef aliases are an option for this instead
> 
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/214
> - ready to be merged
> 
> KDeclarative
> - its KCM module contains generic code used outside of KCM context as well,
> like the GridView
> - Because we want to split up KDeclarative, it is probably better placed in
> kirigami-addons, but we finally need to get that into KF and released.
> - KCM specific QML files should be moved to KCMUtils
> 
> https://phabricator.kde.org/T13970
> - can be closed
> 
> Topics to discuss in a slightly larger scope:
> - solution for the QTextCodec problem
> - determine hard KF6 blocker tasks


-- 
Ahmad Samir