This adds new API in ShaderManager that makes it possible to request a
shader based on a set of traits. ShaderManager generates these shaders
on demand and caches them in a hash table.
* Border Sizes
* Close menu double click
Both are added to the Settings and exposed in the decoration kcm.
As it started to no longer scale the kcm uses a ui file.
Still missing:
* buttons
* custom decoration configuration
* GHNS
* search
The DecorationShadow supports the concept of sharing shadows between
multiple Decorations and this is supported by our Shadow class. But
still the created GLTextures were not shared.
This change introduces a sharing mechanismn for all GLTextures created
for a DecorationShadow. Thus if two decorations share the same
DecorationShadow they will also share the same GLTexture.
QQuickRenderControl brings a few advantages for the usage in Aurorae:
* can create an offscreen window
* eliminate the need for mutex as we control the rendering
* control the tear down of the QML scene (no more crashes in Qt)
In future we can further improve this, by sharing the context, so
that we can use the FBO texture directly. But this first needs
some more work in KWin core.
As we don't hard depend on Qt 5.4 yet it's using ifdefs. Once we have
Qt 5.4 the old code will be removed.
The Compositor is destroyed before the Client and Decorations are
destroyed on shutdown. This meant the Decorations reacted needlessly
on the alpha channel supported. E.g. Aurorae recreated the Decoration
and most likely crashed in Qt.
With this change the signal gets disconnected and the Decorations
just don't do anything.
When a Client gets created the ::createDecoration method is invoked
from ::manage which is called before the Client is added to the
ClientList in Workspace. Thus processing the update fails in the
DecorationBridge as it cannot find the Client.
By delaying to the end of the event cycle we can be sure that the
Client is completely managed and that the scheduled repaint doesn't
fail.
This fixes the missing repaint when a Client starts as inactive.
The test is flaky during the wait for Xephyr. Giving it more time should
hopefully make it more reliable.
The better way would be to switch to the command line argument
-displayfd pipeFd
unfortunately the Xephyr on the CI system does not yet support this
command line argument.
Adjust all components to use the QSharedPointer. Aurorae obviously has
to create a QSharedPointer, Shadow holds a QSharedPointer for the
DecorationShadow (advantage: is kept when the Decoration is destroyed),
and the KCM needs to add a property on PreviewItem to get access to the
Shadow. It's no longer a Q_PROPERTY on Decoration and we cannot re-add
it as a dynamic property (cannot be read from QML side).
if the index is 0, we close the circle, but if the
index is -1 (invalid) we're "somewhere" and step
into the focus chain - reasonably at the beginning
BUG: 340594
REVIEW: 121024
If two or more screens overlap (partially or fully)
we must not create double edges since kwin would
trigger both - since they've the same actions bound
(for sure) the action will called twice (so either
eg. toggle or skip one VD etc.)
BUG: 338381
REVIEW: 120060
Instead of getting size from displayWidth() and displayHeight() use
the information we have from Screens. This means there is only one
place to have the information and by that we can ensure that all
components use the same data to rely on. displayWidth/displayHeight
seem to provide the wrong information when unplugging an output
without disabling the output. This results in rendering artefacts.
But KWin::Screens has the correct information available.
It used to get the individual screen geometries from QDesktopWidget.
We don't need to go through QDesktopWidget any more as Screens
contains all the information we need in a more reliable way.
A new implementation of the Screens interface is added which uses XRandR
directly instead of relying on QDesktopWidget. The implementation is
provided in a new implementation file screens_xrandr.cpp.
XRandRScreens comes with a unit test. Unfortunately it's rather difficult
to provide a proper unit test against XRandR. Xvfb (which is obviously
used on the CI system) doesn't provide the XRandR extension. Also on a
"normal" developer system one would not want to just execute the test as
the results are not predictable (number of available outputs?) and the
test would mess up the setup resulting in nobody wanting to execute the
test.
As a solution to both problems the unit test starts Xephyr as a nested
X server. This allows to have at least some limited tests against XRandR.
Nevertheless there are a few things which I was not able to test:
* multiple outputs
* no output at all
The nested X Server approach makes the interaction rather complex. Qt
opens it's connection against the main X Server thus QX11Info provides
a wrong connection and also KWin::connection() which is heavily used by
xcbutils and thus all the RandR wrappers have the wrong connection. To
circumvent this problem the test is GUILESS. In case it would call into
any code using QX11Info, it would probably either runtime fail or crash.
REVIEW: 117614
Only needed for ScopedCPointer which can be defined in both utils and
xcbutils.h.
Not having utils.h in xcbutils.h makes it easier to have unit tests use
xcbutils.h as it removes the dependencies.
