KF6 Akademy BoF Notes 2021-06-21

[Volker Krause]

KF6 BoF Akademy Notes 2021-06-21

Topics:
- how to continue and when to branch for a Qt 6 port
- implications of Kevin's talk
- better time for the weekly call
- better priorities on the task board

Branching:
- Plasma and things depending on shadertools/RHI would like this to be done 
earlier than later
- a lot of stuff can be done without branching, and doing that in a single 
place avoid duplicate effort

Prioritization:
- use the weekly calls on classifying which tasks are blocking

Weekly call:
- do a doodle poll for this, David E takes care of it (https://doodle.com/
poll/94646r75keyxgqkx?utm_source=poll&utm_medium=link)

Current status:
- Nico got several of them building, but some needing dirty hacks
- KIO has been problematic due to depending on removed Qt API (text codecs, 
network config)
- KCodecs has QTextCodecs in its public API
- we can use the compat library where we only need this internally, but for 
KCodecs we need a proper soluition for that
- KCodecs alternative codec name mapping might be obsolete meanwhile (see 
KCharsets::codecForName), can we remove that?
- QNetworkConfigurationManager: Qt 6.2 has new API for that, just isMetered() 
is missing, but that's nothing KF needs.
- some of the source-incompatible changes can be done now already inside 
#ifdefs, if they are somewhat contained
- https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/108 
still needs work
- should cmake install variables contain a major version? probably not => 
rename KXMLGUI5DIR to KXMLGUIDIR, and so on => do this now
- KNotification has behavior changes (removing of non-API features): announce 
those in the monthly release notes
- QML bindings go into the corresponding frameworks, with the QtQml dependency 
being optional where needed
- for the new QML binding API: https://bugreports.qt.io/browse/QTBUG-92258 
will help (Qt 6.3)
- possibly look at doing the kdeclarative breakup now to identify C++ APIs 
needing improvement for simplifying bindings
- do a KDeclarative breakup BoF for a case-by-case review for things to (1) 
move, (2) remove, (3) rework/redesign to current standards, David E schedules 
the BoF: Tuesday 9am UTC in room 2

Frameworks types and tiers:
- metadata for types is unreliable
- should we drop the types or replace them with something else?
- messages we want to convey with this: (1) cross-platform/platform-building/
Plasma specific (2) runtime dependencies during deployment
- information about supported OSs don't fully cover that
- whether plasma specific libs should be shipped as part of kf first depends 
on all wrong dependencies getting fixed first
- split releases might make it harder for apps to integrate Plasma-specific 
things
- however already the case in some places, like Kate's depending on the breeze 
style
- how to proceed: (1) just new labeling, (2) same time release of two 
differently named library sets, (3) release plasma frameworks with plasma, (4) 
like (1) but move daemons out to Plasma?
- daemons should not be default-started outside of a Plasma session
- review this on a case by case basis during the weekly calls
-------------- 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/20210621/978f1bb1/attachment.sig>