https://github.com/pop-os/cosmic-protocols/pull/28
Allows clients like `cosmic-applet-input-sources` to show which layout
group is active and update it. Currently this is implemented by update
the `xkb_config` to change the layout order.
A fix for the issue reported in
https://github.com/pop-os/cosmic-comp/pull/2450.
Using `block_on` in some places for zbus calls is fine (that's what
zbus's blocking API does; it has its own executor for background tasks),
but this is problematic with `async_once_cell`. If we also use that in
the calloop async executor.
I think ideally we should avoid blocking the main thread on any async
tasks, but for now we can just block in initialization here.
We should avoid creating more than one session connection or more than
one system connection. We should also ideally avoid blocking the main
thread.
For now this still uses blocking in a couple places, but wrapping async
code (which is how `zbus::blocking` is implemented anyway).
This moves the `NameOwners` creation out of `A11yKeyboardMonitorState`,
so it can be shared with other things. We will likely want that for
https://github.com/pop-os/cosmic-comp/pull/465 to define a secured
protocol to pass an fd to the portal, and potentially any other
sensitive DBus protocols implemented by the compositor.
Fixes#2081
This also reverts commit 0f7e53b, because the upstream commit (2e00119)
that introduced this thing was reverted
(https://github.com/Smithay/smithay/pull/1941).
There was also change in the cursor_capture_constraints signature in
smithay 7d992793f.
If we want to use the `org.freedesktop.a11y.KeyboardMonitor` protocol on
Pop!_OS, there is no need to support the Cosmic-specific protocol that
requires an `at-spi2-core` patch.
If we need to use simple async code in a few places, a single executor
may be better than having several threads blocking on async code.
This should probably use the calloop executor, but that's had issues in
cosmic-workspaces, though that may not apply here.
This seems for an SDL XWayland client to restore fullscreen after
unminimize, it needs to see the `_NET_WM_STATE_HIDDEN` state get set
and unset.
In general `_NET_WM_STATE_HIDDEN` does not seem to cover all the
cases covered by waylands "suspended" state, so let's not equate them.
https://github.com/pop-os/cosmic-comp/issues/1510
