Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
KWin was quite good in ensuring that you don't need to install by
passing paths to the tests. The new way is much nicer, so code is
adjusted for the new way. Also if we require a newer ECM in future we
need to support the new way.
No guarantee that the tests don't pick something up from the system env,
that needs more testing.
References: https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled
Test Plan: The tests which loaded helpers pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7543
Summary:
Under wayland we support high DPI putting by putting a separation
between the logical co-ordinate system and the resolution of rendered
assets.
When a window is on a high DPI screen, we should render at the higher
resolution.
Like the window scaling this handles any combination of a 2x scaled
decoration being rendered on a 1x screen or vice versa.
---
This patch is a bit different from the other scaling stuff. We have to
generate the quads *before* we have an updated texture with the new
scale. This means the scale isn't attached to the buffer like elsewhere.
That's why I added a property in TopLevel so there's still one canonical
source and things can't get out of sync.
BUG: 384765
Test Plan:
Crystal clear breeze and oxygen decos on my @2x display
Drag windows to attached @1x display, things still look OK when across 2
screens
Changing the scale of a screen updated the decos instantly
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8600
Summary:
Only needed for kwin_x11 variant (required for the non-composited
Outline). As that's nowadays in the x11 platform, we can move the
complete XRenderUtils support into the platform. Thus KWin core does
no longer require to link it.
Test Plan: Compiles
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7760
Summary:
First step for loading the compositor Scenes through plugins. The general
idea is that we currently needlessly pull in all the Scenes although only
one will be used.
E.g. on X11 we pull in QPainter, although they are not compatible. On
Wayland we pull in XRender although they are not compatible.
Furthermore our current Scene creation strategy is not really fault
tolerant and can create situations where we don't get a compositor. E.g
on fbdev backend the default settings won't work as it does not support
OpenGL.
Long term I want to tackle those conceptional problems together:
we try to load all plugins supported by the current platform till we have
a scene which works. Thus on Wayland we don't end up in a situation where
we don't have a working compositor because the configuration is bad.
To make this possible the switch statement in the Scene needs to go and
needs to be replaced by a for loop iterating over all the available
scenes on the platform. If we go there it makes sense to replace it
directly with a plugin based approach.
So this is a change which tackles the problem by first introducing the
plugin loading. The xrender based scene (as it's the most simple one)
is moved into a plugin. It is first tried to find a scene plugin and only
if there is none the existing code is used.
Test Plan: Tested all scenes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7232
