CompositorWayland will call the present() function even if the beginFrame()
fails, in which case, m_buffer can be null. Also, the present function
has no code to reset m_buffer after it has finished using it.
SENTRY: KWIN-6JD
When an app didn't close, we show a notification to let the user
continue anyway or cancel the logout.
When after 2 minutes no action was taken, the session will logout
anyway. This avoids triggering a shutdown and then leaving the
computer just to find it's been waiting on us to confirm an app
that didn't close.
Makes for a nicer UX when closing app windows after the
message has opened, as a kind of todo list of apps to still
deal with.
While at it, add a space between bullet point and app name.
In preparation of independent tile sets per virtual desktop.
Introduce this class to contain the association between windows and
their quick tile mode: every tile instance will share the same instance
of QuickTileLayout so when tiles will be independent per desktop and
activity, a window tiled to top-left corner, will be so on every
virtualdesktop
This attempts to provide a compromise between the old and the new quick
tiling behavior.
With the proposed changes, if a window is tiled so it occupies the left
half of the screen and Meta+Right is pressed, the window will occupy the
right half of the screen. Quarter tiled windows are tiled as before. If
the window is migrated to another screen, it won't be untiled.
BUG: 493607
Currently, if you press Meta+Up several times and there is no output
higher, you are going to see the following:
- on the first Meta+Up, the window will be tiled so it occupies the top
half of the screen
- on the second Meta+Up, the window will be untiled
This behavior is unexpected, and it looks confusing when you have a
window that's tiled in the top left screen quadrant and press Meta+Up.
It is very inconsistent in comparison to the rest of InputDevice.
Other event types are specified using the signal.
This change drops the TabletEventType enum to make the InputDevice API
more consistent. Unfortunately, it results in a bit of code duplication,
but on the bright side, such a design makes it clear what data you could
expect from the input device.
Window may still be maximized and should be considered as such until
maximized state is actually changed through ::maximize calls for other
side effects to take action.
BUG: 496966
xdg-toplevel doesn't support fractional sizes natively, so when a
configure event is sent, the fractional part is going to be stripped
away.
XdgToplevelWindow::moveResizeInternal() has no matching code to strip
away the fractional part so it could send a configure event when it's
not needed.
When the tabbox shortcut (ex. Alt-Tab) is held pressed, due to the
autorepeat keys mechanism, we'll receive a lot of rapid key events
and quickly iterate through the window list, potentially wrapping
around in an infinite loop.
Instead, let's detect if the key event is in autorepeat and stop the
rapid iteration at the bounds of the window list. Wrapping around is
still possible by releasing and pressing the non-modifier key
(generally `Tab`) again.
Wayland-only for now due to the difficulty of detecting a held key
from a xcb_key_press_event.
FEATURE: 454474
FIXED-IN: 6.3.0
The wl_pointer.leave event should be sent only if the entered surface has
no data devices associated with it (i.e. it's owned by Xwayland), otherwise
Xwayland won't be able to receive new pointer position and the source X
drag client won't be able to move the drag icon window.
This functionality was partially implemented in the activity manager daemon before,
but it doesn't save that information across reboots and it triggers some undesired
animations, which can be supressed if it's done in KWin
BUG: 390295
Refactor the custom keypress handler on the tabbox code so it gets
easier to reason about and modify.
- Early return if the tabbox has not grabbed the shortcut
- Extract the code that matches the key event against a pair of
forward/backward shortcuts into its own method
- Simplify the iteration over the different tabbox modes (each with
its own pair of shortcuts)
- Finally, act on the results of the previous matching
Port away from the deprecated use of `int` variables and operations
for shortcuts and key events, and to Qt::Keys and Qt::KeyModifiers.
This removes deprecation warnings and also enables the tabbox to use
the extra information in KeyboardKeyEvent.
Adds shortcuts to moving a window between custom tiling zones.
This works similar to regular quick tiles, but instead moves a window inside
the zones user has made.
They're separate shortcuts since sometimes you want to quick tile and sometimes you want to
custom tile. They're empty by default.
BUG: 466687
Previously, the search bar and the window heap would forward the keypresses
to each other. The new version has just one forwarding statement, in the
root item, that specifies the exact forwarding order (heap, searchbar,
search results).
According to Keys QML documentation, the order of handling of events is
the following:
* Item- specific key handling, e.g. TextInput key handling
* Items specified in forwardTo
* specific key handlers, e.g. onReturnPressed
* onPressed, onReleased handlers
* parent item
When we type and then press arrow keys, the focus goes to the heap. When we
again press an arrow key, the `forwardTo` is handled before the `onPressed`
handler of the heap, and the heap has a `forwardTo` to the search box, which
accepts the event and moves the cursor within the input box.
By only having one forward to which clearly defines the order of handling we
avoid that.
BUG: 495536
This was added in libinput 1.26 (hence the dep bump) and allows limiting
the logical range of tablet tools between 0.0 and 1.0.
To allow this, two main configuration options were added to Device,
pressureRangeMin and pressureRangeMax. Applications can then query if
this is supported via supportsPressureRange or reset it to defaults
with defaultPressureRangeMin/Max.
The API is a little odd to work with, so we are unaware of if the
tablet tool supports pressure ranges until we receive the first event.
Xvisit::drop() has an assert to confirm that the drop operation occurs
before the X visit is finished, and it seems like there are instances
where the assert statement gets triggered, see the linked sentry crash
report.
It appears like XwlDropHandler will start listening to the Xvisit::finish
signal only after the X visit is left, for example when the cursor moves
to another window.
This change ensures that the XwlDropHandler will listen to the finish
signal right after creating the Xvisit object.
SENTRY: KWIN-37K
If a touched surface is destroyed, we don't want to cancel the entire
touch sequence. Furthermore, during dnd, it's not illegal to destroy
the origin surface after starting the drag operation, the only relevant
part is the source data device.
SENTRY: KWIN-68N
when we use mouse to moveing window, then press Meta + L to lock
screen, then you release mouse, type password to unlock screen,
you will find the window still in moving status.
that means, at this point, the mouse has not pressed any buttons,
but the window will always follow the mouse movement.
Vlad Zahorodnii
Michael Weghorn
Joaquim Monteiro
Kai Uwe Broulik
l10n daemon script
Marco Martin
Laurent Montel
David Redondo
Rémi Bernon
Xaver Hugl
Ismael Asensio
Akseli Lahtinen
Niccolò Venerandi
Joshua Goins