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.
Having blurRegion to identify if a decoration supports blur or not instead of the metadata-json way has the following benefits:
- decorations can now provide both blur or not based on user preference
- theme engines such as Aurorae do not have to enforce blur or not to their themes and they can support blur enabled and disabled themes at the same time if they want to
- blurRegion is empty by default so the Korners bug will be fixed for all solid aurorae themes. Breeze and Oxygen have set **blur:false** so nothing changes for them.
- all aurorae themes that do not require blur will free up system resources by default
