Currently, if kwin/wayland runs without xwayland, the order in which
windows are painted doesn't actually reflect the true stacking order.
If the stacking order has been changed, we need to invalidate the
cached x stacking order. But it's done only when RootInfo is present.
If Xwayland doesn't run, RootInfo is not available and thus window
raising is completely broken.
With this change, the x stacking order will be invalidated every time
some window has been raised, no matter what mode kwin operates in.
No need to create x_stacing by iterating over stacking_order, it can be
copied. We are not performing any operations over it.
Also no need to instanciate the tree until we want to use it.
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.
Summary:
On X11, Workspace stores windows in two lists. One with desktop windows
and the other one with all other windows. On Wayland, desktop windows
and normal windows are stored in the same list - m_allClients.
In order to unify scripting on X11 and Wayland, this change makes the
Workspace class store X11 desktop windows and normal X11 windows in the
same list. It's the responsibility of scripts to filter desktop windows.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29522
Summary: No need to keep them around for no reason.
Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28062
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:
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:
Prefer qobject_cast<> over Toplevel::isClient() because it's more type
safer and makes code a bit more readable.
Hopefully, one day we will be able to get rid of isClient() altogether.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26541
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:
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:
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:
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:
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:
Having a function with a confusing comment, to iterate over the enum,
is mostly confusing. Make it boring by just moving the cast to the one
place that uses it.
Reviewers: #kwin, romangg, zzag
Reviewed By: #kwin, romangg, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23085
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:
Some X clients acting as drag sources might try to optimize finding the current
target window by checking if a window manager, that sets the root window
_NET_CLIENT_LIST_STACKING property, is present. An example for this is Chromium
and since KWin sets the property the drag proxy windows must be added to this
list. Otherwise the origin client will not detect the proxy window and not send
an XdndEnter message.
Test Plan: Manually with Chromium.
Reviewers: #kwin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15628
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 default implementations just return false/nullptr. The advantage of
having this in AbstractClient is that we can reduce the needed casts
from AbstractClient to Client in core as can be seen in this change.
There are more cases which can be improved thanks to this refactoring
which will follow in dedicated commits.
Test Plan: ctest passes
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17890
Summary:
We don't really have to have two different code paths for group
transients and ordinary transients. For now, AbstractClient::hasTransient
is good enough to check the relationship between potential parent and
the transient.
In long term, we need to "invert" the relationship, instead of checking
whether given parent window has a transient, we should check whether
given transient is a transient for a given window so we can keep Deleted
transients above their old parents.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15893
Summary:
The function was introduced in 2d99ef918b.
It's not used anywhere plus we don't need it anymore because
AbstractClient::isActiveFullscreen checks main clients.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16022
Summary:
So far a not-active fullscreen X11 window was kept in the active layer if
the newly activated window is in the same group (that is same client
leader). For example a fullscreen X11 kwrite window is in the active layer
if another kwrite window is active. The two kwrite windows obviously
don't have anything to do with each other, but are in the same group.
This creates problems as it's not possible to raise other windows above
the active not-fullscreen kwrite window. E.g. the panel is stacked below.
The idea behind the check makes sense: if a fullscreen window opens
another window (e.g. a configuration dialog) it should not be put back
to normal layer. Thus the check is adjusted whether the new active
window is a transient to the fullscreen window. Thus the intention is
still the same, but does not cause the problems.
As the code now does not need to differentiate between X11 and Wayland
windows (group only on X11) the Client specific implementation is
removed and the method unvirtual'ed.
BUG: 388310
FIXED-IN: 5.12.0
Test Plan: Test passes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9699
It's confusing to search for usages of ClientList::Iterator and then
discover it's all just commented out. Before falling another time over
it: let's remove it.
Summary:
The xStackingOrder unlike indicated by it's name is relevant for both
X11 and Wayland and contains the stacking order of the windows used for
compositing.
So far it was determined whether it needs to be recreated based on
whether an xcb query is pending. This change introduces a boolean
variable to check whether the stacking order is dirty and guards the X11
specific code to only be run if we have an X11 connection.
This is to my current knowledge the last remaining issue where X11 was
used during the normal Wayland operation mode. Now it should be possible
to re-order the Workspace startup [1] and try to run kwin_wayland without
Wayland support.
[1] Workspace::Workspace and Workspace::init is still highly X11
specific and needs to be split into X11 only and general parts.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7856
Summary:
For a future XFree KWin. Only remaining not guarded usages are in
Workspace::init, but that one needs to be refactored anyway for
becoming X free.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7173
Introduce a method Workspace::markXStackingOrderAsDirty
Summary:
This method replaces the calls x_stacking_dirty = true in the code base
allowing for further refactoring of that functionality.
Remove roundtrip to XServer from Workspace::xStackingOrder
The method xStackingOrder is only used during a Compositor paint pass.
If the stacking order had changed, the method updated the stacking order
from X by performing a sync XQueryTree. With other words we had a round
trip to the X server directly in the paint pass.
This change rearchitectures this area by making better use of xcb. When
we notice that the stacking order changed and an XQueryTree is needed,
we directly send out the request. When xStackingOrder is finally called,
which normally happens a few milliseconds later, the reply is retreived.
In the worst case it still blocks, but in most cases the roundtrip is
gone.
If the stacking order changed again before accessing xStackingOrder the
running request is cancelled and a new request is issued. So whenever we
get into xStackingOrder it will have the current state.
The updating of the xStackingOrder is moved into a dedicated method and
xStackingOrder invokes it through a const_cast instead of operating on
mutable variables.
Test Plan: Normal system usage, no issues
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6323
Summary:
KWin always has a few internal windows around which are not visible.
A QWindow created somewhere, but not shown. Such windows should not
be part of the stacking order.
If they are it breaks code which looks at the top most window in the
stacking order like e.g. SlidebackEffect.
This change ensures that the stacking order gets updated whenever a
ShellClient gets hidden and that internal windows with isShown being
false are excluded from the stacking order.
BUG: 364483
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2636
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
For Wayland transients are popups relative to a parent surface. This
means for a dock window we obviously want them above the dock, otherwise
the context menu would be below the dock.
To not break the existing functionality (which makes sense) we bind
it to whether the transient has a positioning hint - that's only set
for ShellClients.
Merges together the code from ShellClient and Client and removes the
starting differences. Long term it's better to have only one
implementation to prevent diversions in the implementation.
As it doesn't match exactly protected virtual methods are called
which allow more specific implementations for a certain aspect of the
layer resolving.
Vlad Zahorodnii