Meeting notes:
Framework types were supposed to model runtime dependencies/deployment implications and platform availabilty.
(1) Possible approach would be to more explicitly split that regarding platform abstraction and platform building frameworks.
(2) Another approach might be to split out KDE Platform Building Blocks (KPBB) from KF:
Practically that would retain the same versioning/releasing, just change labels.
What of the type system remains in that case?
Most D-Bus use should be the KPBB, not in KF.
KF types would then only be "functional" (no extra processes) and "solution" (extra processes to deploy).
There are tier 3 KPBBs (Baloo, Plasma Frameworks, etc), so there would be a KF <-> KPBB dependency cycle. Better would be having the KF <-> KPBB dependencies only in a single direction:
- KF -> KBPB would mean KPBBs cannot use KF, but KF implementations can directly use any KPBB without affecting its tier. Practically this can mean big dependency chains though.
- KPBB -> KF would mean that platform backends for KF would actually need to be supplied as plugins by KPBB (and there is practically no other way then).
I will go in for for a plugin method as that can also trim deps . Some abstractions could then even be moved to plasma if needed.
Meeting IV notes:
- Just label the frameworks for now, are they "plasma foundation libraries" or not
- Chart dependencies to see how other frameworks tie into that plasma foundation libraries
- Move the plasma foundation libraries as part of Plasma releases at KF6 times
- Also tag the NetworkManagerQt, BluezQt and the like as "wrappers for 3rd party libraries" get them displayed at the end of the list of such