Otherwise it's theoretically possible to create a new ClientConnection
object for the zombie wl_client when its resources are being destroyed.
For example
- process early wl_client destroy notification
- the ClientConnection objects gets removed from the client list in Display
- process wl_resource objects getting destroyed
- if some code calls display->getConnection(zombie_client), it's going to
reintroduce the client in the client list
- process late wl_client destroy notification, it's going to destroy the
original and the clone ClientConnection object
This change prevents reintoducing a clone client object, by keeping the
original for a bit longer until it's actually destroyed. In the future though,
it would be great to kill the client lists in Display and ClientConnection,
and just use `static_cast<ClientConnection *>(wl_client_get_user_data())`.
As Wayland doesn't have a warp event yet, before this commit, warps were
dealt with like normal absolute motion events. This trips up games though,
which don't deal with actual absolute motion events well. As a solution
to that, until an actual warp event is a thing, we send a motion event with
a position + a relative motion event with no motion
BUG: 458233
CCBUG: 482476
Make a roundtrip to the x server to ensure that WM_STATE changes have
been propagated. xcb_flush() is not good enough, there's still a race
condition between the wm flushing its connection and the client reading
window properties.
our plasmoid only listens to signals when the interface was found.
also when switching from 2 to 1 layout we'd emit a signal that the
layouts changed but then we'd throw away our interface leaving
the client wondering what happened to us (and consequently
printing warnings because our service wasn't found)
this specifically resulted in the plasmoid not getting layout event
changes when switching from 1 to >1
BUG: 449531
Unlike X11, on Wayland, the window won't change its maximize mode until
it renders a new buffer. This creates a problem for interactive move
because if it's not careful and moves the window while it's still effectively
maximized, it will look as if the window has leaked to other screens.
This change fixes the problem by making Window::handleInteractiveMoveResize()
avoid move() if the window needs to be unmaximized.
As a bonus, it also allows to unmaximize the windows that are maximized
along only one dimension by dragging them.
Unfortunately, tiling stuff still suffers from the same issue. In order
to fix it, Window::tile() has to be part of double buffered state, like
Window::maximizeMode().
BUG: 449105
BUG: 459218
CCBUG: 482085
XKB_KEY_KP_9 is 0xffb9 while XKB_KEY_KP_Equal is 0xffbd and XKB_KEY_F1
is 0xffbe. So XKB_KEY_KP_Equal, instead of XKB_KEY_KP_9, has the maximum
keysym for keypad keys.
Allow users to configure a virtual edge barrier between screens.
The pointer will only cross over to the other screen after the distance
travelled surpasses edgeBarrier.
Reduce the speed during interactive moveresize, at edges that trigger,
and at the corner.
Only supports wayland. Doesn't have X11 support since it is far too
complicated there.
BUG: 416570
BUG: 451744
When the output layout changes, the Workspace is going to update the
struts and then go through every window and see whether it should be
moved or resized.
On the other hand, the layer shell windows react to output changes on
a timer. Furthermore, it's not synchronized with the workspace rearranging
the managed windows. It means that when Workspace::desktopResized() runs,
the panel struts can be slightly outdated, i.e.
- An output layout change occurs
- Workspace::desktopResized() is called but the struts can be wrong
- some time later, LayerShellV1Integration::rearrange is called, it
fixes layer shell window geometries and struts
- after the layer shell integration has finished rearranging the
layer shell windows, it calls Workspace::desktopResized(), but the
damage had already been caused
With the proposed change, the Workspace and the LayerShellV1Integration
will rearrange the windows in sync.
CCBUG: 482361
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If the client is slow, kwin can receive _NET_WM_MOVERESIZE requests
after user has released mouse buttons. Ideally, the window manager
should refuse starting an interactive move/resize operation in such a
case so it's still possible to finish moving or resizing the window
by releasing mouse buttons.
Strict geometry disables certain user activites; full screen requests
and only sending configure events at sizes the client claims to support.
This was added as a workaround for xterm in 19 years ago. It's a client
side bug as applications can still choose to ignore the configure event,
so kwin shouldn't have to sanitise them in advance. xterm seems to have
fixed it's bug, and pragmatically we know not all window managers
perform these checks so most clients should not be relying on it.
On Wayland this additional check is proving problematic, the handling of
scaling especially fractional scaling is hitting cases where it's better
to always ask the client to do what kwin wants.
Tests that refer to sizeIncrements are dropped as they are only used in
the strict geometry passes which is being obsoleted. Resizing in general
is still tested.
BUG: 481456
NETWM forces a weird X11 dependency on KWin that doesn't necessarily
match what we want to do. Instead we decouple such a central class in
KWin like it's Window from KWindowSystem X11 support.
Signed-off-by: Falko Becker <falko.becker@mbition.io>
SeatInterface currently has a separation of kwin's focus scope to
pointer input with early return guards in notifyPointerEnter and
notifyPointerLeave where clients don't get pointer events.
However we don't update the initial state when a drag is started, this
patch notifies sends a pointer leave to the new drag target before the
data_device enter so things are consistent.
This also brings it in line with Weston and Mutter.
notifyPointerLeave has it's early return removed as for wayland windows
as we know nothing will have pointer focus.
There is a mix of cursor shape names from the CSS W3C specification and
non-spec ones, which is confusing when deciding what cursor shapes need
aliases in Cursor::cursorAlternativeNames().
The current implementation of the `<N>` suffix is still buggy and its
benefits are doubtful. One could argue that visual aids such as window
thumbnails or highlighting the windows are better. On its own, these
numbers don't have strong connections to the windows and can change on
a whim.
