a) if the move is left after the delay is triggered
but before the timer hit, do not cause a stale QT
indication
b) only delay QT if there's actually another screen
on the other side
BUG: 352744
REVIEW: 125250
Holds AbstractClients that is both X11 and Wayland clients. Allows
to easily change code which needs to operate on all clients to get
to them without needing special handling for Wayland clients. At the
same time we are still able to get to the windowing system specific
clients through the old clientList() and waylandServer()->clients().
This fixes yet another regression from the transient refactoring.
The passed in client might be null, so we need a nullptr check. There
are several already in that code.
Was tricky given that I removed a cast there.
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.
AbstractClient::mainClients is virtual and overriden in Client,
allMainClients has only a common implementation in AbstractClient.
In activation.cpp we still need one case where a temporary ClientList
needs to be constructed. Once transients are fully migrated that should
be removable again.
A transient ShellClient has an offset position to the parent surface.
Use this to position the ShellClient properly.
This fixes the random placement of menus.
We take the configuration from the kcminputrc config file, group
keyboard (see plasma-desktop.git/kcms/keyboard/kcmmisc.cpp)
The values are only used for libinput. For backends providing input
events we expect to get repeated key events anyway.
The user might just want to move the window from
one screen to another, no point in wasting time to
show the indicator
BUG: 352050
REVIEW: 125024
FIXED-IN: 5.5
before, hiding the buttons relied on the effect
seeing a paint event for the (with a low timeline
value) what's too wonky at least for instant animations
(certain failure) or when effect exits immediatey
(due to screen edge invocation issues or whatever)
BUG: 351869
FIXED-IN: 5.4.2
REVIEW: 124970
notably *after* storing the old values.
Otherwise the old value is polluted because of
m_hints being nullptr, thus a default value is
returned (instead of the actual old value)
BUG: 347818
FIXED-IN: 5.4.2
REVIEW: 125007
Theory:
----------
because PresentWindowsEffect::screenCountChanged() is shortcut
for "if (!isActive())", but the desktopgrid doesn't call
PresentWindowsEffect::setActive (or at least
PresentWindowsEffect::screenCountChanged), so the effect can
"miss" the increasing screen count change (it sees the signal,
but ignores it) and when desktopgrid calls it, it assumes the
m_gridSizes array is big enough (but it isn't)
Steps:
----------
1. effects are loaded, 1 screen present
2. 2nd screen gets added, but inactive effects ignore that
3. desktop grid gets activated, updates according to screen count,
calls presentwindows for screen #2
4. presentwindows data is only prepared for one screen from step 1
=> BOOM
BUG: 351724
CCBUG: 326032
FIXED-IN: 5.4.2
REVIEW: 124960
Thomas Lübking