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.
Adds all internal ShellClients into a dedicated list. This ensures that
we don't perform "normal" window management on them.
In addition we add them to the top of the stacking order. This restores
behavior as it is on X11: internal windows are using BypassWindowManagerHint
and thus on top of everything.
Windows that "belong" to the desktop are
kept visible and do no break the state on
activation/mapping
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
Moves the properties and the base implementation into AbstractClient.
Methods invoke a new protected virtual method which is implemented in
Client to update the TabGroup.
This is an alternative approach suggested by the
NETWM spec.
The advantage is, that windows are not minimized
at all what apparently lead to some confusion
about the nature of the mode (which was abused
to tidy up) and a secret config key to allow for
that unrelated behavior.
Instead the ShowDesktopIsMinimizeAll key is removed
and replaced by a dedicated script + shortcut.
Bonus: less code to remember "minimized" windows =)
when restacking for shaded windows and uncomposited tabboxes
the group check should not be applied since we know better
eg. to restore a former order
CCBUG: 186206
REVIEW: 122469
Callgrind analysis showed that this method has room for improvement.
The bottle neck is mapping the Unmanaged against the list of windows
retreived from xcb_query_tree. The number of windows in that list is
rather large (>1000), which turns the loop into an expensive path.
Workspace::findUnmanaged seems to be too expensive for that due to the
overhead of using a functor and multiple method calls. The Inl. cost
before the optimization for checking ~55,000 windows is 2.46.
The change uses a good old const-iterator based loop over the unmanaged
list to check for the window. This reduces the Incl. cost for checking
~55,000 windows to 0.28.
REVIEW: 122067
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
