(cc: plasma-devel for heads-up, not subscribed there, please re: only to kfd)
Am Samstag, 17. April 2021, 16:11:24 CEST schrieb Luigi Toscano: > Several "needs input" tasks are related to Plasma. > Maybe it would be better to focus on Plasma next time and involve Plasma > people, and find out which tasks are really blockers for KF 6.0 and which > are not. In fact several Plasma items are not really blockers for KF6. > > In the worst case, the first plasma-frameworks release could be delayed > until Plasma 6 is closer to be ready. Other frameworks don't depend on it > (just one dependency in KRunner, but it is deprecated, to be removed at > branching time). Maybe frameworksintegration? (to be checked) It seems these days the only real user of plasma-frameworks & krunner libraries is the Plasma shell itself, with other applications only providing plugins/extensions and only targeting Plasma again. IIRC Amarok was the only other project ever making use of Plasmoid technology, but not sure that still works even. For KRunner, which also seems to have been once designed for other, non-shell purposes, I am not aware of anything else. And with there being strong development coupling when it comes to evolvement of features, perhaps it makes sense to move those two modules from the product KDE Frameworks to the product Plasma and its release cycle for Plasma 6? After all there are already a few Plasma-specific libraries released as part of the Plasma set, so those two would not be at odds there. Just a random thought from a non-Plasma contributor having seen what seems at sometimes struggles to get changes into plasma-frameworks & krunner in time for new Plasma major versions and being backward-compatible to older Plasma versions. Not sure if such a change, if wanted, would be doable already now for Plasma 5 even, at least without creating major headaches for any stakeholders? Cheers Friedrich
