KF6 meeting notes 2021-07-19

[Volker Krause]

Topics remaining from last week:
* Raising the Qt minimum version to 5.15.2: https://mail.kde.org/pipermail/
kde-frameworks-devel/2021-July/118039.html
* STL use in KF implementation: https://invent.kde.org/frameworks/kio/-/
merge_requests/484
* Friedrich's alternative ECM branching proposal: https://mail.kde.org/
pipermail/kde-frameworks-devel/2021-July/117990.html

New topics from this week:
* C++17 porting documentation: https://mail.kde.org/pipermail/kde-frameworks-devel/2021-July/118146.html
* https://phabricator.kde.org/T14727
     
5.15.2 update:
* Require 5.15.2 now
* Pay attention to not use the slow porting API from QStringView in hot paths 
during the 5 era.
    
STL use in KF:
* The use of STL in the implementation is certainly ok.
* We do not want needless mass porting from Qt to STL containers though, when 
changing this there should be an actual reason (example: better container for 
the job, double-lookup prevention, etc).
    
ECM major version/release strategy
* there is a lot of Qt-independent code in there where branching isn't 
necessary
* branching would make work easier for ECM developers, but harder for ECM 
consumers
* for the very Qt5 specific parts (e.g. things relying on qmake or the install 
dir handling), we are defacto branching by splitting those files into a 5 and 
6 variant, which also reduces the risk of regressions in 5
    * for install dirs we probably want to reduce the shared code between 
those two that were introduced during splitting
    * for those cases we can then start from a clean slate for Qt6
* it's worth thinking about a removal strategy for deprecated stuff, e.g. 
dropping things deprecated for N releases for a sufficiently large N?
    * this is only an option for things that actually have a replacement (like 
new install variables)
    * this is not useful for e.g. old Qt versions, as those then become 
unbuildable in modern environments (the "Helio use-case")

C++17 Porting Docs
* there is actually not a whole lot
* not mentioned in the thread yet:
    * std::auto_ptr
    * std::random
    * http://www.cplusplus2017.info/removed-features-from-c17/
    * related problem: output of gperf/bison/yacc/flex/etc code generators.

Static Plugins
* needs to be switchable, as this can't follow BUILD_SHARED_LIBS (a dynamic 
interface can work both with static and dynamic plugins)
* should KPlugin[Factory|MetaData] abstract plugin loading and meta data 
access for both static and dynamic plugins? yes!
    * https://phabricator.kde.org/T14314

Co-installability of System Settings
* probably not required, due to Plasma also not being coinstallable?

Plasma plugin versioning:
* https://phabricator.kde.org/T14724 - David E says this can go
-------------- 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/20210719/d8458677/attachment.sig>