Currently it is impossible to manage containments that are not on an active screen. They can't be recovered to an active screen or deleted.
Our multi screen handling also isn't very robust. It tries to be clever and map connectors, but it is not a problem with a strict single defined answer.
We also lack a good import/export of containments. It's tied into look and feel, we would be better off splitting that out.
# Proposal
## Management:
For a given selected containment one can:
- remove a dead containment
- export/import a containment
- change the screen/activity assignments
## Better screen handling:
Containments are configured thusly.
Screen becomes string based with one of following options:
Primary, Secondary, Tertiary, "E-DP1", "HDMI-0"
i.e either an integer index, or a QScreen::name
(This could be serial number instead, as long as it's something unique)
Acitity is string based with one of the following options:
Any", "My Activity1", "My activity 2"
(stored as regular activity UUIDs using the null activity ID for all activities, maybe you can choose 0-N activities?)
This gets presented in the UI. We can put some marker next to the current activity/screen used (two screens will match, by index or by ID)
# UI
{F9881721}
This would be accessible through the burger menu in edit mode
# Implementation in PlasmaShell
On every screen or activity change the mapping is re-evaluated and changes are applied.
The algorithm is as follows:
foreach possible containment we check *in the used-specified order* if it matches any situation of corresponding screen + activity
For desktops we apply the first containment that matches per screen, for panels we apply all matching containments
if any desktops remain unpopulated a new desktop containment is created with the following corresponding characteristics:
- screen = ScreenN (index based)
- activity = currentActivity
No new panels are ever created from this situation
It is appended (i.e at the bottom) of the list of possible containments.
## Rationale
By allowing the user to choose the order we get the maximum flexibiliity for covering all possible cases. It also very explicit meaning we don't need to worry too much about error cases - if someone creates two desktops that are both on screen 2 and activity 2, then it is determined which one will load.
The default case is also kept relatively simple, if one doesn't open this screen they will get something sensible as all their containments will be screen-index based and "just-work" for some definition of that
## Specific changes
ScreenPool takes on the job of QGuiApplication for the puposes of having an ordered list of screens and signifying changes.
It also performs detection of overlapping desktops internally and removes all inside ScreenPool (current logic is in ShellCorona)
ScreenPool drops the mapping
int Containment::screen() gets deprecated, it was a mess anyway
It gains a `QString Containment::screenId` this is the configured screen string in the format above
To get the current screen, use the relevant ContainmentView
The main "normal" edit mode view remains untouched and is the default behaviour.