Split plasma-framework
Open, Needs TriagePublic

Description

Current plans from last Akademy, still might need some discussion

Plasma::Package should be removed as it's already split

Plasma theme stuff would become a new framework (for plasma mobile apps etc)

A lot of the applets/dataengines/containments/scriptengines implementation code should become a library within workspace with no C++ API promises. Exact details TBD

declarativeimports/calendar -> to be replaced by something not terrible

declarativeimports/plasmaextracomponents -> deprecated by kirigami

declarativeimports/platformcomponents -> deprecated by kirigami

declarativeimports/core/colorscope -> deprecated by kirigami(ish)
declarativeimports/core/datamodel -> QSFPM goes to KItemModels

DataModel...we'll see

declarativeimports/core/svg -> along wtih theme
declarativeimports/core/framesvg -> along wtih theme

declarativeimports/core/windowthumbnail -> public import in workspace

declarativeimports/core/tooltips -> needs deciding

@bshah and @nicolasfella are working on a replacement for the calendar stuff, should help here and with KDeclarative.

Anything related to applets/

Can you expand on that? We surely want to keep Plasma::Applet a proper usable library thing?

I definitely intend to keep everything in libs for the latte-dock case, but tying that to the plasma schedule should be fine.

We also definitely need to make sure kate/whatever can ship an applet without having the slightest tie-in on anything released with plasma.

Personally I think it should be a goal that near everything should be do-able with just the runtime dependency on the Plasmoid attached property and a custom import as needed. I don't like our optional C++ subclassing.

That said, it's clear we need to discuss this part in more detail as a group. I think there's consensus that we want some of the implementation detail to move, but that still leaves quite a grey area.

mart added a subscriber: mart.Oct 31 2019, 1:29 PM
ndavis added a subscriber: ndavis.Nov 10 2019, 8:19 AM
ervin moved this task from Needs Input to In Discussion on the KF6 board.Mar 28 2021, 1:32 PM
ervin moved this task from In Discussion to Needs Splitting on the KF6 board.Mar 28 2021, 3:47 PM

there's two actionable subtasks: Creating new repositories for the SVG and Dataengine stuff

Something else to consider is moving the Plasma themes out (breeze(-dark) to breeze, oxygen to oxygen, air to /dev/null)

Plasma theme stuff would become a new framework (for plasma mobile apps etc)

Mobile doesn't use the PC3 any more

declarativeimports/calendar -> to be replaced by something not terrible

calendar already moved to p-w

mart added a comment.Jul 10 2023, 2:40 PM

Plasma::Package should be removed as it's already split

done

Plasma theme stuff would become a new framework (for plasma mobile apps etc)
declarativeimports/core/svg -> along wtih theme
declarativeimports/core/framesvg -> along wtih theme

KSvg done, plasma own svg still to be removed from p-f

declarativeimports/core/colorscope -> deprecated by kirigami(ish)

Almost done, some mrs in progress

declarativeimports/core/datamodel -> QSFPM goes to KItemModels

KItemModels on in place, last port of remaining datamodel usages still to be done

A lot of the applets/dataengines/containments/scriptengines implementation code should become a library within workspace with no C++ API promises. Exact details TBD

Plasma5Support in workspace, scriptengines and dataengines stuff removed from p-f

declarativeimports/calendar -> to be replaced by something not terrible

declarativeimports/plasmaextracomponents -> deprecated by kirigami

some classes still used, to review what to keep, remove

declarativeimports/platformcomponents -> deprecated by kirigami

already removed

declarativeimports/core/windowthumbnail -> public import in workspace

What's the status of this?

declarativeimports/core/tooltips -> needs deciding

I think they're fine as they are