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
Our server announces the DpmsManagerInterface and in the DRM backend
we announce support for Dpms on the OutputInterface (if the Output
supports it) and we connect to changing Dpms requests.
This ensures that the Compositor doesn't perform compositing and doesn't
run the compositing timer if e.g. all outputs are dpms disabled. Thus
we don't render any more, don't trigger wakeups and block applications
from rendering if they properly implement the frame rendered callback.
By default Outputs are considered to be enabled. This allows a
concrete backend implementation to mark outputs as disabled (e.g.
if dpms has put outputs into powersaving mode). This allows the
Compositor to disable itself if outputs are not visible anyway.
If an Output went into DPMS standby we need to re-enable the Output
once we get any input event.
For this we connect to the signals of InputRedirection once we go
to standby. Once we enable again, we disconnect (to not handle the
events all the time), blank the screen (initial modesetting) and
trigger a complete repaint.
