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.
`privileged` now only indicates if a client is "sandboxed", i.e. it has
a security context, where the sandbox engine isn't cosmic-panel.
So replace the field with a method that's a bit more descriptive.
This is a first use of the new hooks system, which allows customizing
cosmic-comp at compile-time.
In this case, the view() function of CosmicWindow / CosmicStack is
hooked and the hook can change what is rendered as the header bar.
Signed-off-by: Yureka <yuka@yuka.dev>
Allows other programs to depend on the cosmic_comp library crate and
start a cosmic-comp in their process by calling `cosmic_comp::run()`.
Later, customization parameters can be added to `run()`.
Note that the interface of the cosmic_comp library crate is not stable
in any way and might change anytime.
Signed-off-by: Yureka <yuka@yuka.dev>
Tested on `SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=1 supertux2`, using
XWayland. If the game starts with fullscreen configured, it minimizes
immediately on start. But after this change, this no longer happens.
This hopefully will improve behaviors with various X11/wine fullscreen
clients. It may fix
https://github.com/pop-os/cosmic-comp/issues/1510, though looking at the
video the behavior there may be a bit different.
It seems https://github.com/pop-os/cosmic-comp/pull/1638 caused an issue
in cosmic-workspaces, where if there are multiple toplevels, when
dragging a toplevel, the drag surface would appear in capture for other
toplevels.
For now, omit drag surface in toplevel capture without `draw_cursor`.
Though I guess ultimately we do want it for metadata cursor capture in
the portal, but not in cosmic-workspaces? Maybe the protocol needs some
additional option for this...
`CosmicMapped::cursor_positon` may have worked previously, but doesn't
now.
This is based on the code used for seperate cursor capture sessions.
Maybe this could be consolidated in some way.
But this seems to work. Including for rotated outputs.
