Skip to content

Plasma screen mapping action plan

Split from #21 (closed) to be more concrete

Current state

We keep a cache of connector names to IDs We currently have a primary screen that's always on "screen ID 0". If this changes we swap IDs in the connector map

A containment lives on a given ID Containments gets the screen ID from the current state the screen is on. We assign containemnts to a screen based on the screen ID in the containment. This is as much of a circular loop as it sounds. This is hidden by having two properties "screen" and "lastScreen", but it's still complicated.

Things aren't as reliable or predictable as they should be.

What we want

What we want is to keep screen IDs on a per-setup basis. some people on plugging into a dock might want the panel and main wallpaper to move to the secondary monitor, some will not.

Ultimately that's user preference that has to come from a user controlled setup somewhere. We know this and have "primary screen", but this doesn't scale to 3.

The current state uses connector names to solve that, which we know sucks because they're volatile. Other proposal suggest using screen identifiers, but that doesn't work on it's own because it doesn't solve the case of us sometimes wanting to swap sometimes not. We need some layer of indirection at some layer.

"if you have two designs for the same objective you don't have a design at all"

Any proposal of a combo of primary screen and some other pattern is mixing two designs which is bad for both for code and UX.

Propsoal

We have primary screen, lets add a secondary, tertiary, etc. Ultimately this means a port from a boolean on the output to more of an "index".

It'll be best to follow the current flow where possible rather than having a separate path to primary. Therefore:

  • Kscreen UX changes from a checkbox to a dropdown (if >2 monitors are present)
  • On X11 the index is set as a property on the randr output (I tested that this is possible and works)
  • On wayland we proxy the data through kwin which acts as a broker (means adjusting the protocol, but that's in our control)
  • Plasmashell's screenpool gets this data

Within plasmashell:

  • ScreenPool gets some new watchers

  • Most this connector name stuff can go in the bin

  • DesktopViews and PanelViews follow screen indexes

    • Within the view itself we now map that to a screen based on ScreenPool

  • Containment's can only be moved between screen by explicit user actions. (the management config or drag and dropping a panel)

  • Containment can get a nice simple setScreen at a corona level instead of the current system. There is no need for the virtual

  • We don't necessarily need to add a property in OuptutConfig, the order outputs appear would suffice. This solves the risk of any duplication

Within kscreen:

  • We don't need to save the value in the Ouptut class, the order of outputs in the Config object / object file could be enough. That way we don't have the possibility for two outputs at index 2 or whatever.

Challenges

Migration

The only migration case we need to think about is users with 3 screens as we're building on primary. Worst case, we don't try to do anything?

Sending screen indexes atomically

We probably still want to use the primary output that's into X, so do I put the properties only for screen after that? Or just keep them in sync? If it's a property on the output how do we update them all atomically?

Plasmashell needs to handle kscreen not existing

We still need fallback logic, without complicating the code.

Edited by David Edmundson