(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
