Currently, if some script attempts to resize a window while it's being
interactively resized, the corresponding change won't be propagated to
the X server.
The main reason for that is that we don't want to configure the frame
window, the wrapper window, and the client window twice. However, since
Xcb::Window keeps track of the last configured geometry, we can adjust
X11Client::updateServerGeometry() so it only configures windows that
have mismatching geometry.
By doing so, the setFrameGeometry() function can be called by scripts
even when the associated X11 window is being interactively resized.
Note that this bug doesn't affect Wayland windows.
BUG: 426988
Toplevel::debug() is one of annoyances that you need to deal with when
implementing a new client type. It can be tempting to just write "this"
to the stream, but it will result in a crash.
In order to make implementing new client types easier, this change
introduces a debug stream insertion operator overload that works for all
kinds of the Toplevel class.
Currently, we have two functions that update the color scheme for a
client - updateColorScheme(QString) and updateColorScheme(). Even though
they both share the same name, they do different things. The first one
sets the specified color scheme, while the other determines the color
scheme preferred by the client and assigns it.
This change refactors the color scheme initialization code so we no
longer need those two methods. The setColorScheme() method sets the
specified color scheme, and the preferredColorScheme() method returns
the color scheme preferred by the client. Sub-classes of AbstractClient
can override the preferredColorScheme() method in order to add support
for platform-specific color scheme protocols.
The end result: color scheme related code is a bit more comprehensible.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
If the Xwayland process crashes, it will bring down the entire session
together with itself. Obviously, we don't want that. At least, Wayland
clients should survive the crash.
This change refactors relevant X11 parts to handle Xwayland crashes in a
less fatal way.
In order to handle Xwayland crashes better, a pair of start() and stop()
methods had been introduced in the Xwayland class to allow starting and
stopping the Xwayland process at any moment.
If we detect that the Xwayland process has crashed, we will immediately
stop the Xwayland server, which in its turn will deactivate the socket
notifier and destroy all connected X11 clients. Unfortunately, a couple
of subtle changes in X11Client::releaseWindow() and Unmanaged::release()
had to be made to ensure that we are left with a valid state after the
Xwayland server has been stopped.
In rare cases, Workspace::restoreFocus() may fail, for example when the
most recently activated client is about to be destroyed or unmapped.
If it happens that we cannot restore the focus, then mark the window in
FocusIn event as active.
CCBUG: 424223
If AbstractClient::setFrameGeometry() is called from a slot connected
directly to the frameGeometryChanged() signal, then is there a good
chance that kwin will fall into an infinite recursion. However, that's
the case with only X11 and internal clients.
The root cause of the infinite recursion is that both X11Client and
InternalClient compare the new geometry against the geometry before
update blocking. In order to fix the bug, we simply need to ensure that
updateGeometryBeforeUpdateBlocking() has been called before we start
emitting the frameGeometryChanged() signal.
Furthermore, a couple of tests were added to ensure that we won't hit
this subtle bug again.
Unfortunately, a0c4a8e766 has a major bug
where clients that track focus events may get confused by focusToNull().
One such a notable example is Dota 2. It tracks the focus events to
minimize itself after the keyboard focus has been lost as well stop
playing music while it's in background. So, when we call focusToNull(),
Dota 2 will receive a corresponding FocusOut event and ask the window
manager to minimize it. It doesn't really matter that the FocusOut
event is going to be followed by a FocusIn event because when a window
is minimized, kwin will activate the next one in the focus chain.
Since those issues can't be fixed from the window manager's side, this
patch partially reverts a0c4a leaving only the autotest.
BUG: 424223
FIXED-IN: 5.19.4
The new signal can be useful if one wants to watch a toplevel for buffer
geometry updates. This can be especially useful for input related code
because the position of the upper left corner of the main surface is used
to compute the input transformation matrix.
We may call setActive() on a window that is being deleted. We cannot
guarantee that at that moment the X11 window or the Wayland surface is
still valid. So, the best course of actions is to do nothing.
BUG: 424255
Depending on the current focus stealing prevention level, it's possible
for kwin to call XSetInputFocus() on a window that already has the input
focus. In which case, we won't receive the corresponding FocusIn event
and the client will remain inactive from kwin's perspective even though
it isn't.
In order to work around this issue, we can move the input focus to the
null window. By doing so, it's guaranteed that we're going to receive
the matching FocusIn event for the client.
This commit indirectly fixes a bug where fullscreen games are displayed
below panels.
Due to a bug in the XI2 protocol, clients have to reset scroll valuators
on XI_Enter because the scroll valuators might have changed while the
pointer was elsewhere. The XI_Enter event is usually sent when an input
device enters the window, but it can also be generated by a passive grab.
If an XI_Enter event has been generated by a passive grab, the client
should not reset scroll valuators. Unfortunately, there is no any
reliable way for the client to determine if an XI_Enter event has been
sent in response to a deactivated passive grab. A correct fix for the
scroll issues in GTK apps would involve changes in the XI2 protocol.
As a work around, we can hold a passive grab only if the current mouse
wheel action is either "Activate and scroll" or "Activate, raise, and
scroll."
BUG: 394772
FIXED-IN: 5.19.3
In most cases, we don't need to react to client geometry changes, but in
code that deals with server-side window decorations, we need to react to
client geometry changes. The problem is that frame and client geometry
updates are not correlated even though there is a connection between the
frame geometry and the client geometry.
This change introduces the client geometry in the Toplevel class in order
to allow monitoring client geometry updates from DecoratedClientImpl.
Kwin sends out undated WM_TAKE_FOCUS client messages. Gtk based
applications such as Firefox react to these by handing focus to one of
their subwindows using XSetInputFocus(), and pass on the null time field
that they received in the client message to XSetInputFocus().
If for whatever reason the application (firefox) is slow to process the
event, it might issue that XSetInputFocus() message at a time when it
has already lost focus to the next application. This results in Firefox
stealing back the focus from the next application. Normally, such an
occurrence would not happen, as the server could tell by the time field
that the message is stale.
Until 2016 (e73e331f35) kwin *used* to
send a valid timestamp, but this got deliberately broken to appease some
Java Applications which were "extremely picky" and would refuse focus.
This was based on the assumption that no other toolkit used the
timestamp from take focus events which is now proven to be false.
ICCCM document states:
Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may
receive a ClientMessage event from the window manager (as described in
section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid
timestamp (i.e. not CurrentTime ) in its data[1] field."
BUG: 421068
Summary:
In order to allow shading wayland clients, this change moves core shade
code from X11Client to AbstractClient.
Test Plan: Shading still works on X11.
Reviewers: #kwin, cblack
Reviewed By: cblack
Subscribers: cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29512
Summary:
This change drops Workspace::sendPingToWindow() in order to better
separate X11-specific and more generic code.
Test Plan: Still able to close X11 windows.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29472
In case Xwayland does not use multiple buffers, the currently attached
buffer is going to be destroyed if the frame window is resized. It may
render the previous and the current window pixmap invalid and thus result
in visual artifacts when an X11 client is being interactively resized.
In order to avoid the visual artifacts, this change disables support for
synchronized resizing for X11 clients if the version of Xwayland is less
than the version in which Xwayland started using multiple buffers, i.e.
1.21.
Differential Revision: https://phabricator.kde.org/D29250
Given that we now query the current X11 time stamp on Wayland, we can
enable synchronized resizing for Xwayland clients.
Differential Revision: https://phabricator.kde.org/D29250
Summary:
As is KWin only had 1 Cursor which was a singleton. This made it impossible for
us to properly implement the tablet (as in drawing tablets) support and show where
we're drawing.
This patch makes it possible to have different Cursors in KWin, it makes all the
current code still follow the mouse but the tablet can still render a cursor.
Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
Reviewers: #kwin, cblack, davidedmundson
Reviewed By: #kwin, cblack, davidedmundson
Subscribers: davidedmundson, cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28155
Summary:
Prefer virtual methods that take QRect and QSize rather than multi-int versions.
Makes for clearer API and reduces the amount of code that was taking all of the
components and turn it into a class.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28283
Summary:
If we know that we are going to disobey resize increment and aspect ratio
geometry hints, then there is no point for trying to constrain the client
size according to those hints. Just return early.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27031
Summary:
Currently, there are a couple of issues with sizeForClientSize(). First
of all, we have a method called clientSizeToFrameSize() which does similar
thing except applying geometry constraints and checking window rules. The
other issue is that sizeForClientSize() is doing a bit too much, it checks
window rules, it applies a bunch of geometry constrains. Sometimes it
does not perform conversion between client sizes and frame sizes!
This change attempts to address those issues by replacing sizeForClientSize
with two similar methods and changing semantics of some methods of the
X11Client class.
The most significant difference between sizeForClientSize() and the new
methods is that neither constrainClientSize() nor constrainFrameSize()
check window rules. This is up to users of those methods. In many places,
we don't have to check window rules because we check isResizable(),
which returns false if the frame size is enforced by a window rule.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26828
Summary:
Typically by default newly added toplevel windows are added only to the
current activity.
Initially windows with no borders were added to all activities. This
causes problems particularly now with the newer frame extents support
leaving window behaviour quite inconsistent.
Since the time of the original code the taskbar gained control for
controlling activities allowing at least one method of changing them.
This means we can use this as the new filter.
BUG: 274931
Test Plan:
Opened gtk3-demo
Switched activities, it wasn't on the new one
Went back, altered it through the taskmanager, it worked
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27690
Summary:
Otherwise the content overflows the frame when scrolling.
QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
Test Plan:
Before:
{F8121150}
After:
{F8121152}
Reviewers: #kwin, #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27558
Summary:
Otherwise the content overflows the frame when scrolling.
QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
Test Plan:
Before:
{F8121150}
After:
{F8121152}
Reviewers: #kwin, #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27558
Summary:
This regression was introduced by me, sorry. The client window may be at
location other than (0, 0), in which case we have to move it to (0, 0)
to ensure that the client contents is not covered by window frame.
BUG: 417584
FIXED-IN: 5.18.1
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27456
Summary:
We need to provide the input geometry and the input transformation
matrix for Xwayland clients in order to make sure that input events
are correctly mapped from the global screen coordinates to the
screen-local coordinates.
BUG: 417444
FIXED-IN: 5.18.1
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27375
Summary:
Not all Client classes have support for the maximized mode. Therefore,
it can be made opt-in to reduce the amount of plumbed methods.
Unfortunately, there a few places, which don't have any connection with
the maximized mode, where AbstractClient::geometryRestore() is used, so
it cannot be made 100% optional at the moment.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27169
Summary:
Nothing special about this patch except of the removal of code that forces
_NET_WM_STATE_BELOW and _NET_WM_STATE_ABOVE. If the client window is
compliant with the EWMH spec, then _NET_WM_STATE_BELOW and _NET_WM_STATE_ABOVE
will be in sync with keepBelow() and keepAbove(), respectively.
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27120
Summary:
Currently we have two signals that are emitted when the Toplevel's geometry
changes - geometryShapeChanged() and geometryChanged(). The former signal
is used primarily to invalidate cached window quads and the latter is
sort of emitted when the frame geometry changes. But it's not that easy. We
have a bunch of connects that link those signals together...
The worst part about all of this is that the window quads cache gets
invalidated every time a geometry update occurs, for example when user
moves a window around on the screen.
This change introduces a new signal and deprecates the existing geometryChanged
signal. frameGeometryChanged is similar to geometryChanged except that it is
emitted when an _actual_ geometry change has occurred.
We do still emit geometryShapeChanged signal. However, in long term, we
need to get rid of this signal or come up with something that makes sense
and doesn't require us to waste computational resources.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26863
Summary:
When a window is being interactively resized, its contents may jump. The
reason why that happens is because KWin renders partially resized client
window. Composite extension spec says that a window will get a new pixmap
each time it is resized or mapped. This applies to the frame window, but
not to the client window itself. If the client window is resized,
off-screen storage for the frame window won't be reallocated. Therefore,
KWin may render partially resized client window if the client doesn't
attempt to be in sync with our rendering loop. Currently, the only way
to do that is to use extended frame counters, which are not supported by
KWin.
So, in order to fix visual artifacts during interactive resize, we need
somehow forcefully re-allocate off-screen storage for the frame window.
Unfortunately, Composite extension doesn't provide any request to do
that, so the only option we have is to resize the frame window.
BUG: 415839
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26914
Vlad Zahorodnii