modifiersRelevantForTabBox handles modifiers being consumed, which is wrong for the
tabbox; all it needs is to ignore capslock. To ensure that happens, this commit adds
a separate method for modifiers relevant for the tabbox.
BUG: 473099
Specification for data control states:
"The first selection event is sent upon binding the
wlr_data_control_device object."
This differs to other data devices.
CCBUG: 459389
The show_window_menu request is in surface-local coordinates,
which include any client-side window shadows.
Translate the menu coordinates so the window shows up in the
right spot.
At commit time, the newest commit that's ready will be chosen, ensuring that
cursor updates added just before commit time can't delay the primary plane
update unnecessarily
This change adds support for xdg_wm_base v6, which introduces
xdg_toplevel suspended state.
The suspended state is tied to the visibility of the window item so the
effects could possibily "resume" window content updates.
`Placements::placeSmart` searches for an optimal position for windows, attempting to minimize overlap. The core of this algorithm tracks the
client's height and width in `ch` and `cw`, which have been adjusted by -1. This simplifies logic determining the bottom and right points of a
window when you are starting at the top and left points.
However, this decision requires adjusting that number by +1 when doing the opposite: determining the top and left points when you start with
the bottom and right points.
placeSmart cycles through window locations, searching for acceptable nooks and crannies to fit a window in, nicely. It begins by checking
for places to put the top left corner of the window which abut another constraint. If that fails, it then tries to place the bottom right
abutting a constraining feature.
After finding a suitable bottom (or right) location, the top (or left) location must be determined, requiring the -1 adjustment to be undone.
This patch adds that +1 back in.
# The bug it solves
This error can be seen by opening a bunch of windows that are placed using the "Minimal Overlapping" rule. The open space on the screen will be tiled from left to right, and then top to bottom in the windows. Once no more windows can be placed like that, the next window will be placed at the extreme bottom-right corner. However, it will be one pixel too low and one pixel too far to the right---if you try to move the window, it will "snap" to the correct spot.
This single pixel may seem minor or even irrelevant, but when you use the "Present Windows" desktop effect on a multiple-monitor setup, this one pixel will cause the window to show up on both monitors.
Otherwise we will still react on a frameGeometryChanged signal
and try to relayout the popup when its transient parent was
already set to null leading to a crash.
BUG: 472532
