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:
The new method provides a generic way for destructing clients. Notice
that we can't just delete clients because we may need to discard
temporary window rules, which is usually done in destroyClient().
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27821
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:
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:
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: m_xdgShellSurface represents an xdg-toplevel, not an xdg-surface.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26975
Summary:
We duplicate ping code in a few places. This change introduces a dedicated
method for sending ping events to an xdg-toplevel. In long term, it can be
used for sending "test" ping messages at random interval.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26974
Summary:
According to the xdg-shell spec, configure events carry the maximum
window geometry size. If a client wants to enforce aspect ratio, it
may attach a buffer with smaller size. We need to account for that
when determining frame geometry in the commit handler.
I'm targeting 5.18 branch.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26886
Summary:
Currently, the input geometry for client-side decorated clients matches
the frame geometry, which makes it impossible for a user to resize such
clients by just dragging invisible area near window borders.
BUG: 416346
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26716
Summary:
So far the window geometry from xdg-shell wasn't implemented as it should
be. A toplevel must have two geometries assigned to it - frame and buffer.
The frame geometry describes bounds of the client excluding server-side
and client-side drop-shadows. The buffer geometry specifies rectangle on
the screen occupied by the main surface.
State and geometry handling in XdgShellClient is still a bit broken. This
change doesn't intend to fix that, it must be done in another patch asap.
Test Plan: New tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24455
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:
Move unrelated code out of XdgShellClient::addDamage() into a separate
method.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24328
Summary:
Currently the init method is just a big pile of connects to lambdas,
which makes the code very difficult to read and moreover to change.
This change moves most of those lambda to handleFoo methods so one has
more clear view of what the init method is actually doing.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24197
Don't put method definitions in the header file of XdgShellClient class
as it makes the code visually inconsistent. InternalClient is a good
example of how the header file of a subclass of AbstractClient class
should look like.
This change also cleans up the order of things in the header file, thus
making it a bit more obvious where new things should go.
Summary:
Rename ShellClient to XdgShellClient in order to reflect that it
represents only xdg-shell clients.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23589
Summary: wl-shell is deprecated, and pretty much no one uses it.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23562
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:
Managing lifetime of objects during tear down is a bit clunky in KWin
mostly because the wayland server outlives the workspace.
3f4e733468 tried to tackle one aspect of this problem, but the proposed
solution is good only in short term. If a ShellClient wants to discard
force temporarily rules, it needs to access RuleBook, whose lifetime is
bounded to the workspace, no matter what happens. Otherwise, the force
temporarily rule will be applied again on the next startup.
It's worth to mention that there was another attempt to address this
problem, see commit 826b9742e9. It was reverted because some internal
clients may need to destroy Wayland resources during tear down.
This change takes another approach. In order to ensure that ShellClient
can access RuleBook during tear down, we manually destroy Wayland clients
in destructor of the Workspace class. Something is done already for X11
clients.
Reviewers: #kwin
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22986
Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
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:
Most parts of this function are only relevant for X clients, in particular
the "fullscreen hack". Therefore split up the function into the AbstractClient
subclasses.
Test Plan: Manually and autotests still pass.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: graesslin, zzag, kwin
Tags: #kwin
Maniphest Tasks: T11098
Differential Revision: https://phabricator.kde.org/D18128
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
Summary:
The size passed to an XDG shell configure request should match the
window size of the given window, we don't want to include the size of
any shadows that may be drawn by the client.
Kwin has the same concept of geometry for both window management, input
and rendering.
In order to approach this in a way that does not risk any regressions
with kwin's current structure AbstractClient::geometry remains the
canonical source and we handle the window within that internally within
ShellClient treating the windowGeometry as a set of margins from this.
This is part of a much bigger task (T10867). This patch addresses
windows growing when starting a drag based resize.
BUG: 403376
Test Plan:
Unit test
gtk3-demo
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20937
Summary:
When user asks KWin to show desktop, the compositor just raises every
desktop window, it doesn't attempt to minimize normal clients, etc.
Because desktop windows contain stuff like background and icons, the
compositor has to raise all clients that are somehow correlated with
desktop (e.g. panels, etc). Otherwise it would pretty weird to show only
desktop background.
Currently, not all plasmashell's clients are raised when the compositor
shows desktop because belongsToDesktop is not implemented for ShellClient.
BUG: 404801
Test Plan:
* Show desktop;
* Open Kickoff (without this patch Kickoff is not visible).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19386
Summary:
Everything on the wl_surface is double buffered.
When we create an XdgShell toplevel or popup we shouldn't treat it as
attached until it's committed to the surface.
A client should commit the surface after it's sent it's initial state of
the Xdg topLevel; minimumSize, title, app_id, etc.
By blocking sending configure events we will have flushed the correct
initial state before sending a single atomic correct event to the
client. It also adds a hook to re-evaluate rules now that all properties
are set.
Arguably this applies to WlShellSurface too, but I've left it unchanged
as it's deprecated and hard to verify real client behaviour.
Test Plan: Ran all unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18583
Summary:
We can handle the case of a null size inside
ShellClient::requestGeometry and that makes that method more robust.
With that we don't need to handle separate code paths in
the handler of RequestGeometryBlocker.
It's not an exact identical code path, but everything still works out.
If the geometry is unchanged, we'll save the positionAfterResize but
when we apply it doSetGeometry will no-op.
There's also an assumption that toggling maximised will always send a
valid size, but that's true for the current state.
Test Plan: Ran unit tests
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19331
Summary:
placeIn did not handle the case for a popup not having had the size
already set and only being available via
m_xdgShellPopup->initialSize(). This is needed if we want to call placeIn
at the correct time, before the window is mapped.
There was also a logic bug when sliding popups. We called the
confusingly named setX thinking it would be move the popup keeping the
width the same. In practice it moves the left edge keeping the right
position the same. This wasn't an issue as the size was
discarded.
Handling the resize constraint is not yet done, but it should now be
even more trivial.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18956
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
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
The only place where this method is used is testMaximize. Though that
usage is not justified. We're checking what KWayland already checks.
Test Plan: Compiles, all tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18635
Summary:
This is only relevant on Qt and when WlShell is used.
This was only the case before Qt5.10.
We will depend on Qt5.12 next release.
Static Qt builds which are that old typically wouldn't contain QtWayland
Test Plan: Compiles. Not used in tests
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18594
Summary:
Does something similar to our existing ServerDecoration, but based
around XDG Shell patterns and with a few subtle differneces.
We'll probably still need both in kwin for the forseeable future as GTK3
won't ever change from using the KDE Server Decoration.
Test Plan:
Relevant unit test. It's a bit simpler as spec states
toolkits must follow what the compositor configures if they
bind the interface.
Modified plasma-integration to remove ServerIntegration
(as Qt5.12 has native support) all my windows look and act the same.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17756
Summary:
The dialog invoked through user actions menu takes the internal uuid as
command line argument which allows to query the required information
from KWin instead of using X11.
This allows to enable the system for Wayland windows.
In order to replace the usage of ClientMachine in the rules dialog the
dbus interface is extended by a value whether the window is on the
localhost. This is exposed through a virtual method on toplevel which is
overridden in ShellClient and there always returning true.
Test Plan: Run a nested Wayland and opened the dialog on a wayland window
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17750
Summary:
Support XDGShell Positioning. This gives a client a lot more control
over where the popup will be placed as well as control over how to
handle constraints. i.e what to do if the popup doesn't fit.
trasientOffset was replaced with a method on the client as semantically
it's the role of the client to handle constraints.
Both slide and flip constraint adjustments are implemented. Resize
constraint adjustment will be handled in a future patch.
WlShell is handled by treating it as 1x1 sized anchor with slide
constraint adjustment.
Test Plan:
Manual test of a client implementing xdgpopup exists in kwayland
Extensive unit test here
Existing WlShell test passes (after D16314 which fixes the original)
XdgPopup has a new unit test suite against manually calculated values
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16325
QSize default constructor does not set width/height to 0,0 but instead
to an invalid size -1,-1. This went unnoticed as Qt5.12 corrected these
values to the intended 0,0.
Reviewed By: Roman Gilg
Summary:
Previously when updating the state we would send a configure event with
the size 0,0. This means the client chooses the size. For regular window
this works as most toolkits treat this to mean the size that we
previously requested. It's not explicit in the spec either way.
For maximised windows it's a problem, the spec clearly states that when
maximised clients must follow the size given. Telling the client to be
0,0 doesn't make sense.
By always sending our last requested size we remove any ambiguity.
Test Plan:
Ran
Maximised some windows and changed focus
WAYLAND_DEBUG showed we weren't sending a configure with 0,0
after startup
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16055
Summary:
The Scale effect and the Glide effect have to animate only ordinary
windows(i.e. the ones that are considered to be apps).
On X11, in order to distinguish ordinary windows from combo box popups,
popup menus, and other popups, those effects check whether given window
is managed.
On Wayland, there is no concept of managed/unmanaged windows.
XDG Shell protocol defines 2 surface roles:
* xdg_toplevel;
* and, xdg_popup.
The former can be used to implement typical windows, the ones that can
be minimized, maximized, etc.
The latter can be used to implement tooltips, popup menus, etc. Thus,
that's a good criteria to filter popup windows.
CCBUG: 398100
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: #kwin, graesslin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15117
Vlad Zahorodnii
Nicolas Fella
Vlad Zahorodnii
Roman Gilg
Nate Graham
David Edmundson
Martin Flöser