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.
A quad might have a null size in case it has a null width or null height.
Not just one dimension.
BUG: 236353
BUG: 210467
FIXED-IN: 5.4.2
REVIEW: 125131
On popular demand!
This change tracks how modifiers are used and detects a modifier only
key press/release. That is:
* no other key is pressed when the modifier gets pressed
* no other key gets pressed before the modifier gets released
If such a press/release is detected, we call a configurable dbus call.
The possible shortcuts can be configured in kwinrc, group
"ModifierOnlyShortcuts". The following keys are supported:
* Shift
* Control
* Alt
* Meta
As value it takes a QStringList (comma seperated string) with
service,path,interface,method,additionalargs
E.g. to invoke Desktop Grid effect on Meta key:
[ModifierOnlyShortcuts]
Meta=org.kde.kglobalaccel,/component/kwin/,org.kde.kglobalaccel.Component,invokeShortcut,ShowDesktopGrid
I do not intend to add a config interface for it. Let's keep it a hidden
way.
REVIEW: 124954
We need to send a fake HoverMove event on minimized to remove all
hovered states of the decoration.
At the same time we need to ensure that no further hover events are
sent to a minimized client.
BUG: 351984
FIXED-IN: 5.4.1
REVIEW: 124997
regardless of whether the pushback is forced down or the user
has deactivated it or whatever. The edge is waiting from previous
activation and we need to prevent immediate reactivation since that
may cause duplicate action and unwanted state toggles
BUG: 351627
CCBUG: 351869
FIXED-IN: 5.4.1
REVIEW: 124888
The test put a reference to the XCB::Window as data
to the _net_wm_transient property, not the window ID
This "works" (you get various garbage transients for
the leader in addition) as long as the window id itself
is the first item in the structure (because that is what
the test resolves to verify what it has done) bug fails
when the XCB::Window structure changes and anything
is the first item (or, btw., when the compiler feels
to re-align the structure and adds some padding...)
So let's fix the test by at least passing the proper
data reference.
is FIXED-IN: 5.4.1
REVIEW: 124888
also see REVIEW: 124864
The one contains a set of paths which might be the reason why e.g on the
CI the include dir cannot be constructed. Let's see what will happen....
CCBUG: 351776
We no longer need to have the event dispatcher created before starting
the QApplication, thus we can leave it to the QPA plugin to creat it.
Also we don't need to implement our own dispatcher any more but can
use one from Qt5PlatformSupport as we link it anyways. The special
need for dispatching the WaylandServer is no longer needed as we can
explicitly dispatch it from the QPA plugin if needed.
Our QPA plugin does not require a running Wayland server at startup,
so we can move the startup after creating the application.
Nice side effect: --help works now.
