Commit graph

4 commits

Author SHA1 Message Date
Vlad Zahorodnii
9a7ab8a62e Rework async geometry updates
Window management features were written with synchronous geometry
updates in mind. Currently, this poses a big problem on Wayland because
geometry updates are done in asynchronous fashion there.

At the moment, geometry is updated in a so called pseudo-asynchronous
fashion, meaning that the frame geometry will be reset to the old value
once geometry updates are unblocked. The main drawback of this approach
is that it is too error prone, the data flow is hard to comprehend, etc.

It is worth noting that there is already a machinery to perform async
geometry which is used during interactive move/resize operations.

This change extends the move/resize geometry usage beyond interactive
move/resize to make asynchronous geometry updates less error prone and
easier to comprehend.

With the proposed solution, all geometry updates must be done on the
move/resize geometry first. After that, the new geometry is passed on to
the Client-specific implementation of moveResizeInternal().

To be more specific, the frameGeometry() returns the current frame
geometry, it is primarily useful only to the scene. If you want to move
or resize a window, you need to use moveResizeGeometry() because it
corresponds to the last requested frame geometry.

It is worth noting that the moveResizeGeometry() returns the desired
bounding geometry. The client may commit the xdg_toplevel surface with a
slightly smaller window geometry, for example to enforce a specific
aspect ratio. The client is not allowed to resize beyond the size as
indicated in moveResizeGeometry().

The data flow is very simple: moveResize() updates the move/resize
geometry and calls the client-specific implementation of the
moveResizeInternal() method. Based on whether a configure event is
needed, moveResizeInternal() will update the frameGeometry() either
immediately or after the client commits a new buffer.

Unfortunately, both the compositor and xdg-shell clients try to update
the window geometry. It means that it's possible to have conflicts
between the two. With this change, the compositor's move resize geometry
will be synced only if there are no pending configure events, meaning
that the user doesn't try to resize the window.
2021-05-25 06:17:41 +00:00
Bhushan Shah
119b00f896 inputmethod: use output geometry for positioning keyboard when locked
otherwise it will take the panel strut in account when positioning
inputmethod on lockscreen and that will not be positioned correctly.
2021-05-07 14:18:57 +00:00
Aleix Pol
65ad7ffb27 inputmethod: do not cover panels with the input method (e.g. virtual keyboard)
This way we can adapt the panels themselves to show useful UX like
hiding the keyboard or switching.
2021-02-23 12:10:28 +00:00
Vlad Zahorodnii
93e0265e4e Move source code to src/ directory
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.

This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.

We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
2021-02-10 15:31:43 +00:00
Renamed from inputpanelv1client.cpp (Browse further)