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:
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:
By the time AbstractClient::setupWindowManagementInterface() is called,
it's possible for a window to already have an application menu, and not update them
afterwards.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28150
Summary:
We have duplicated code in InternalClient and XdgShellClient to create
decorations. In order to get rid of the code duplication, this change
introduces a method that AbstractClient subclasses can call to create
a window decoration.
Test Plan: Tests pass.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27822
Summary:
Currently, we have only one shell client type - XdgShellClient. We use
it when we are dealing with Wayland clients. But it isn't really a good
idea because we may need to support shell surfaces other than xdg-shell
ones, for example input panel surfaces.
In order to make kwin more extensible, this change replaces all usages
of the XdgShellClient class with the AbstractClient class.
Test Plan: Existing tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27778
Summary:
Clarify that AbstractClient::minSize() and AbstractClient::maxSize()
specify the minimum and the maximum client size.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26829
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:
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:
We need to schedule a workspace repaint in minimize() to ensure that
there are no ghost windows on Wayland.
Test Plan:
Make sure that window minimization effects are disabled,
minimize a window. Without this patch, you are going to see a ghost
window. With this patch, no ghost window.
Reviewers: #kwin, davidedmundson, apol
Reviewed By: #kwin, davidedmundson, apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27516
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:
In long term, we want to split XdgShellClient into several classes. One
class for xdg-toplevel clients, and the other one for xdg-popup clients.
xdg-popup clients are much simpler than xdg-toplevel clients, they can't
be maximized or shown in full screen mode, they can't be interactively
moved on the screen, and so on. In the end, we will have to plumb many
pure virtual methods, which looks a bit ugly.
This change makes support for the minimized state in AbstractClient
optional so we don't have to add those no-op methods and keep code more
or less "clean."
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27163
Summary:
In long term, we want to split XdgShellClient into several classes. One
class for xdg-toplevel clients, and the other one for xdg-popup clients.
xdg-popup clients are much simpler than xdg-toplevel clients, they can't
be maximized or shown in full screen mode, they can't be interactively
moved on the screen, and so on. In the end, we will have to plumb many
pure virtual methods, which looks a bit ugly.
This change makes support for full screen mode in AbstractClient optional
so we don't have to add those no-op methods and keep code more or less
"clean."
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27162
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:
If the frame geometry is changed in any away, for example if the client
has been moved, resized, or both, setFrameGeometry() will schedule a layer
repaint for the visible geometry before and after the update.
When there is a resize effect, we only send requests to the client window
to render contents at the new size. setFrameGeometry() is not called and
therefore no layer repaints are scheduled.
Only the resize effect knows what parts of the window or the screen must
be repainted and thus it must be responsible for scheduling repaints.
A full repaint in AbstractClient::performMoveResize() is scheduled mostly
for historical reasons.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27167
Summary:
QDateTime::fromMSecSinceEpoch uses Qt::LocalTime by default. This involves an
expensive localtime conversion. So instead force things to use UTC, as there
is no need for timezone information when tracking durations.
This is especially noticeable on Bedrock Linux, which uses a Fuse mounted
/etc, which is slower than a plain /etc and causes quite some slowdown there.
See https://github.com/bedrocklinux/bedrocklinux-userland/issues/140 for
details.
Test Plan: The screenedge unit test still passes.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: zzag, anthonyfieroni, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27114
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
The stored buffer geometry can be useful for detecting whether the
buffer geometry has been changed.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24659
Summary:
Rename geometryBeforeUpdateBlocking in order to better reflect that it
corresponds to the last frame geometry.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24658
Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
clang-tidy has a check that converts all usages of null pointer literals
to nullptr keyword. However, there's a small issue related to QFlags<T>.
Apparently, QFlags<T> has a constructor that takes a pointer and if you
pass 0 to it, clang-tidy will replace 0 with nullptr, e.g.
NET::States(0) -> NET::States(nullptr)
Even though passing nullptr is totally correct, it looks very weird.
Test Plan: Complies.
Reviewers: #kwin, gladhorn
Reviewed By: #kwin, gladhorn
Subscribers: gladhorn, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23948
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
This change makes easier to refactor geometry handling in the future.
The main motivation for avoiding using geom directly is to make code
more readable and ensure that the geometry is updated only through
designated methods, e.g. setGeometry, plainResize, etc.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23072
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:
All internal clients live in the x stacking order, but when such a
client is closed, it will be moved to the normal stacking order.
Given that internal clients don't specify the desired layer, they will
be moved to the normal layer, which is not really what we want because
it means that the task switcher window will be placed below docks.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21116
