If two displays have the same edid (which shouldn't happen, since edid
includes a serial number, but is somewhat common in practice with
identical monitors), match output stack by comparing both edid and
connector name.
If we get the same edid but a different connector, `set_output`
truncates but also adds the new one. (Before adding edid matching, this
would have just added to the output stack.)
`prefers_output()` will requrire a connector name match if the edid of
the current output is the same as that of the output being compared.
If the user explicitly moves a workspace to an output, assume that is
where the user wants it, so it shouldn't be moved back to a different
output in the future.
For persistent workspaces, the explicitly set workspace is the one that
will be stored, instead of trying to track an unbounded list of outputs
persistently.
This was mapping `UnderlyingStorage::Memory` to `None`. I don't see any
reason for this. Though this also shouldn't change behavior since
`TextureRenderElement` doesn't provide `underlying_storage` currently.
Previously, this was not updating the workspace indices on either the
old or new set, and left no workspace on the old set with `Active`
state. It also didn't add a workspace if the last workspace was removed.
`ext_workspace_handle_v1::coordinates` defines the coordinate as
"an N-dimensional grid within a workspace group". So it is not
expected that the coordinates are unique between different groups, or
establish any geometry between different groups.
Whether we use one workspace per output or allow workspaces to span
outputs in the protocol, the whole workspace group is on the same set of
outputs. So I think this holds in any case.
I don't think we rely on this anywhere.
Requires https://github.com/Smithay/smithay/pull/1676.
This changes two things:
* `Workspace::is_empty` no longer checks if there are activation tokens,
but a separate `Workspace::can_auto_remove` checks if the workspace is
empty and has no activation tokens.
- When we add workspace pinning, that can also be checked there.
* `Workspace` no longer contains a `pending_tokens` list that is updated
on `refresh`. Instead, `can_auto_remove` takes the xdg activation
state as an argument.
Since `Workspace::refresh` normally is run for focused workspaces, this
fixes allowing non-focused workspaces to be removed when an activation
token expires. It seems generally good to avoid tracking the activation
tokens in two places, and this is probably more efficient than needing
to refresh in more places.
By splitting this, we still don't remove an empty workspace if it has a
pending activation token, but we also don't add an empty workspace for
an activation token.
This mitigates the confusing behavior with activation tokens that aren't
used, but having to wait a few seconds in some cases before a workspace
is removed is still a little confusing. (We probably want `cosmic-term`
and `cosmic-workspace` to either consume the activation tokens they are
passed, or not be passed tokens when started by keybinding?)
Fixes https://github.com/pop-os/cosmic-comp/issues/1099.
On `output_remove`, if the output a workspace is moved to had no
non-empty workspaces (or did, but had an empty one active), the empty
workspace would remain active, and the workspace that was active on the
removed output is no longer visible.
Instead, change the active workspace to the one that was active on the
removed output.
This addresses another edge case where hotplug results in an empty
workspace, followed by other non-empty workspaces, and generally seems
like a better experience.
This could be further restricted by only applying if `new_set` is not on
the active output (to not mess with what the user is interacting with,
even it's an empty workspace) or only if the old `set` was the active
output, etc. But it seems good without further restriction.
