[6/6] Make autotests create fake input devices
This test was the only one where input() could return a nullptr. With
this test removed, autotests can now expect input() to always return a
sane valid value and are therefor simpler to write.
That test belongs in kwayland-server anyway and kwayland-server's test
suite already tests that starting without XDG_RUNTIME_DIR is a no-no
thing
[5/6] Make autotests create fake input devices
Migrate all input simulation functions from kwinApp()->platform()->...
to the their counter part in the Test namespace.
[4/6] Make autotests create fake input devices
This translates all required input simulating methods from
kwinApp()->platform()->... to seperate functions in the Test namespace.
[3/6] Make autotests create fake input devices
This commit adds back all three VirtualInputDevices for simulating
keyboard, touch and pointer input events from autotests.
[1/6] Make autotests create fake input devices
The goal of this patch set is simulating user input in unit tests via
InputDevices and no longer use the Platform to fake input. This matches
more closely with how input is processed when running a full plasma
wayland session, i.e. with the DRM and libinput backends.
This line had several problems:
1. Using un-namespaced `units` properties
2. Using `width` in a Layout
3. Using largeSpacing instead of gridUnit for indentation
All are fixed with ths commit.
The QStringView::to[Number]() methods in Qt5 cause one extra allocation
compared to the QStringRef counter-part. As long as we aren't on a hot
path this is probably not worth the extra #ifdef though.
when an aurorae theme does not contain "mask" element we can safely assume that blur is not supported. In such case all blur calculations must not run at all. This will make all solid aurorae themes much lighter by default.
kwin disables ptrace for a good reason - to prevent other processes from
attaching to kwin and snooping sensitive data or taking control of kwin.
But, that will also make things such as memory statistics unavailable to
read, etc.
On the other hand, the supported platforms where kwin runs all have
security measures in places to forbid shady processes ptrace'ing kwin.
For example, on Linux it's YAMA.
On Linux, by default, a process can ptrace only its descendants. For
example, this can be used by debuggers; otherwise you would need to be
the superuser to attach to any process.
This change drops our ptrace logic in favor of system provided security
measures. It allows the System Monitor to gather kwin's memory usage
statistics and also simplifies code, the current debugger detection
logic is not really robust.
If the system provided security measures are proven to be insufficient,
we can add the ptrace disabling logic back, but it would be great to
avoid that because system monitor won't be able to gather resource usage
statistics, which can be useful for detecting memory leaks in plasma
wayland session, etc.
A lot of integration tests rely on the fact that there is a
window decoration.
The `KWIN_BUILD_DECORATIONS` pretty much only disables
build of Aurorae window decoration plug-in but otherwise
has no impact on KWin's core code base in terms of ifdefs
or dependencies required.
Re-enable building decorations to unbreak those tests.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
when aurorae decorated windows become maximized and back to normal, after a while they all start to disable blur for their decorated maximized windows.
- bug was tracked down to aurorae fault sending empty QRegions for its maximized windows. What probably happens is that because mask FrameSvgItem enabled borders change from AllBorders to NoBorder, mask FrameSvgItem calculations can not catch up
- the new approach is lighter than the previous one and simpler as margins and enabledborders for mask framesvgitem are not changed and in the c++ side no QRegions calculations are needed at all for maximized windows
- in my system with the new code changing from normal window to maximized one feels a bit snapper
the target is called ConfigCore, the relevant cmake config is not.
notably KF5ConfigConfig.cmake is the present file, so look for the
correct name, otherwise the dependency isn't found
Qt6 insists on that. We can do this either by including the moc files,
or by including the corresponding headers in the header defining the
properties, the former seems cleaner when possible.
