Summary:
There are rules that have to be applied only once, e.g. every Remember
and Apply Initially rule, as well rules that need to configure the client,
e.g. size, etc. In the best scenario the compositor would evaluate such
rules when the client is about to be mapped.
This change limits window rules only to xdg-shell clients because right
now only this protocol lets compositors to intervene in the client
initialization process. Also, it makes things a bit easier for us on the
compositor side.
xdg-shell protocol satisfies most of ours requirements to implement window
rules, but not all of them. If the client is about to be mapped for the
second time and its size is forced by a rule, then compositor may need
to configure it. Currently, xdg-shell protocol doesn't have any mechanism
that a client could use to notify the compositor about its intent to map.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: fmonteiro, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19411
Summary:
Given that our QPA now creates native offscreen surfaces, we no longer
need the QOffscreenSurface guard introduced by 61956025f.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22198
Summary:
Unfortunately Aurorae decoration engine creates several internal clients
per each decoration. One of those clients represents QOffscreenSurface,
which is not a toplevel. Given that no QWindow object will be found for
such clients, m_internalWindowFlags contains undefined value.
Luckily, QOffscreenSurface sets FramelessWindowHint flag, but because
InternalClient is not able to find matching QWindow object, cached
QWindow flags won't have that hint set.
Thus InternalClient will attempt to decorate QOffscreenSurface. A new
Aurorae decoration will be created, which means a new QOffscreenSurface
will be created, which means a new Aurorae decoration will be created,
and so on.
This change restricts subset of internal clients that can be decorated.
Only clients with valid m_internalWindow can be decorated. If m_internalWindow
isn't null, then m_internalWindowFlags is guaranteed to be valid as well.
BUG: 407612
FIXED-IN: 5.16.3
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22136
Summary:
Window open/close animation effects should not animate the outline
because the end result is a bit awkward.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19886
Summary:
Most of the functionality which is special to internal clients is moved
from ShellClient to InternalClient. As KWin's qpa is still bound to the
Wayland protocol InternalClient inherits from ShellClient. Due to that
some aspects in ShellClient are "weird". ShellClient still detects
whether it's an internal client and uses the variable m_internal to
capture the state. This is required as we cannot use the isInternal
method. Most of m_internal usage is in init which is called from
constructor of ShellClient. Thus it's not possible to call into virtual
methods of InternalClient.
Also some of the code is duplicated and some methods are temporarily
marked as virtual.
The next step will be to remove ShmBuffer for internal windows which
should decouple the two implementations further with the long term goal
of having InternalClient inherit AbstractClient directly.
Test Plan:
Run nested KWin, triggered outline (OpenGL case) and debug console (shm case).
InternalWindow unit test still passes.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18569
Vlad Zagorodniy