Even when handling request for a surface, `surface.client()` may return
`None`. This occurs, for example, if a protocol error is signaled; the surface
remains alive for some time, but `client()` returns `None` immediately after
`post_error` was called.
`WlrLayerSurfaceUserData` contains a `WlSurface`.
`LayerSurfaceAttributes`, which is stored in the surfaces `data_map`,
contains a `ZwlrLayerSurfaceV1`. This, somewhat subtly, is a reference
cycle that causes a leak. So one of these references needs to be weak.
I noticed this issue with Valgrind, but this can also be reproduced by
adding drop impl to `LayerSurfaceAttributes` that panics. Before this
change, running `simple_layer` in anvil and exiting it never drops the
`LayerSurfaceAttributes`. With the change, the panic happens when a
layer surface is closed.
Remnants of this commit:
5a0b08c804
It removed the code that decremented or even just accessed the counter,
leaving it to overflow, which causes panics with overflow checks.
This property is not always passed with events (well actually only with
DeviceAdded and DeviceRemoved), so it's an option.
Actual handling of this property should be done downstream, for exmaple
to create multiple outputs represented by different X11 windows.
This method, while undocumented, is a lot more robust than an intermediate
shell. It works by passing a pipe to the Xwayland cmdline invocation. When
Xwayland is ready, it writes the display number and a newline to the pipe.
While we're at it, we can remove the hard dependency on Calloop, so that the
Xwayland instance can be used with other event loops.
This seems to match the behavior of sway, and fixes
https://github.com/pop-os/cosmic-comp/issues/437.
If `!data.dropped`, `cancelled` has already been sent. If `data.finished`,
`dnd_finished` has been sent. Otherwise, sending `cancelled` here seems
correct.
Each call to `set_text_input_rectangle` changes the position of the
popup and also will result in popup repositioning, thus notify
users when such request occurs.
The location and text cursor area where separated, since one is used
for the rendering, and the other one is original location.
It seems I missed one place where a grab could be removed.
This fixes an issue on cosmic-comp where a surface being destroyed
during a DnD drag from that surface would result in the DnD surface
still displaying. (For instance, closing cosmic-workspaces with a
keybinding while dragging).
(I guess the `&mut D` argument to `with_grab` is needed after all... I'll
probably not create another dozen PRs adding and removing it again. It's
an internal API anyway.)
This also updates `cursor_shape` call the same logic.
This fixes calls to `set_cursor` during drag-and-drop. Nautilus is a
good client to test this with, though most drag-and-drop clients should
work.
The Wayland spec doesn't seem that specific about how `set_cursor`,
pointer focus, and drag-and-drop interact. But this seems to mostly
match Sway: the surface loses pointer focus at the start of
drag-and-drop, but can still set the cursor.
I'm not sure if this is likely to be desirable or undesirable when there
is a grab other than a drag-and-drop grab. It could be restricted to
drag-and-drop, but there is not currently any way in Smithay to check
what the drag is, or if there is a drag-and-drop operation. But it
should be possible to downcast the `dyn PointerGrab<D>`, I guess.
This fixes an issue I noticed where cancelled drag-and-drop in clients
like Firefox and Nautilus caused a window to ignore pointer events until
losing and regaining focus. It seems calling the `.ungrab` method at the
end of `with_grab` means calling it after pointer focus is restored, and
clients seem not to handle the `wl_pointer.enter` before the drag is
actually over.
Deferring the focus restoration as well is slightly complicated to
implement, and seems problematic when it involves a serial. Maybe there
shouldn't be any input events after the `*set_grab` call but before
returning, but this seems cleaner.
Taking a reference to the handler in `*InterHandle.*set_grab` is a bit
annoying, but easy enough to deal with, and allows this to work more
cleanly. This seems reasonable as long as we don't have a better
solution to the whole `GrabStatus::Borrowed` thing.
This was already supposed to happen, but I hadn't noticed that these
functions don't delegate to a method of the innter handle, like they do
with touch.
This is a breaking API change, since these functions then need to take
`&mut D`. But this seems reasonable since the equivalents for
pointer/touch already require that, and `&mut D` should be available to
call wherever these are used.
`unset` is called when a grab is removed with `unset_grab` or replaced
with `set_grab`.
This fixes https://github.com/pop-os/cosmic-comp/issues/403. There are a
couple other grabs in Smithay and cosmic-comp that they run before
unsetting the grab, that may cause issues if the grab is removed without
running it. So this seems useful in general.
The usual value for one wheel tick is 15, not 3. This can be verified
with Firefox by scrolling on a TTY backend vs. on the winit backend
(since this particular fallback is used on the winit backend).
