Allow X11 clients to activate a window.
This shares the logic with xdg-activation. It might make sense to handle
the urgent hint on an X11 Window natively, but for now this just marks a
workspace as urgent on activation in the same way xdg-activation does.
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.
This protocol is now the upstream solution in at-spi2-core/orca for
registering keyboard grabs and watching key events. It should also be a
bit better than the current verious of our custom Wayland protocol for
this purpose.
Like Mutter and Kwin, we currently restrict this to only be called by
the client that holds the name `org.gnome.Orca.KeyboardMonitor` on the
session bus. We also send the `KeyEvent` signal only to registered
watchers, rather than broadcasting, as DBus does by default.
This monitors `NameOwnerChanged` events to keep track of what unique
names own what well-known names on the bus. This allows dbus protocol
implementations to check that callers own a certain name.
To initially populate the list of dbus name owners, `ListNames` is used
at start. Then `GetNameOwner` is lazily invoked to populate owners that
exist at start. To avoid calling that for every single name on the bus.
This also keeps track of unique bus names, which don't require any
additional methods or signals to monitor. This allows us to also detect
if a client has disappeared from the bus.
The `COSMIC_ENFORCE_DBUS_OWNERS` allows disabling checking of owned
names.
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
cosmic-comp panics here after launching an app from the app tray overflow popup. While it may indicate a panel issue that I also need to look into, it seems to work fine if we don't unwrap on this option.
Replacement for https://github.com/pop-os/cosmic-comp/pull/1687, that
works correctly with multiple outputs.
We don't want another window to show a focus indicator while a window is
being dragged, so keep the window in the focus stack. If a window is
being moved out of a stack, change the focus from the stack to the
window.
`refresh_focus_stack()` doesn't seem to be called here, but for good
measure, make sure that calling that function also won't remove a
`CosmicMapped` from the focus stack if it is currently part of a move
grab for the seat.
`Action::Close` already used the keyboard focus target, but some other
bindings didn't. Presumably it's most intuitive if all "current window"
key bindings affect the window with keyboard focus.
These used the focus stack on the `focused_output()` (the one with
keyboard focus), so I guess the main impact is when the keyboard target
is a window being dragged? Then the binding will operate on that window,
or have no effect.
This seems related to some of the behaviors discussed in
https://github.com/pop-os/cosmic-comp/issues/453.
This seems like the correct way to use an `IndexSet`. It shouldn't be
possible to have multiple entries that match, since it's a "set".
We can't define `Borrow<CosmicMapped> for FocusTarget`, so the blanket
impl of `indexmap::Equivalent` won't work, but implementing seems fine.
This is identical to the wlr protocol, and Smithay has implementations
for both.
New clients should use the `ext` protocol where present. Not sure how
widely used it is yet, but we probably should have both for now.
Some users have complained about not supporting clipboard managers. But
this was possible, but hidden under the `COSMIC_DATA_CONTROL_ENABLED`
env var.
Since the security context protocol exists now to provide a way to not
expose a protocol like this to sandboxed clients, it should be safe to
expose this now.
This is only intended to be used by `orca`.
I guess `|_| true` was a placeholder for a potentially more restrictive
check, but use this for now, anyway.
