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:
Glow textures already have the red, green, and blue channels
premultiplied by the alpha component (because of QImage), thus we can't
use GL_SRC_ALPHA for sfactor in glBlendFunc.
BUG: 403570
Test Plan:
Before:
{F6592391}
After:
{F6592392}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18803
Summary:
This gets rid of the dark area that may appear between very different colors by doing the blur in SRGB colorspace.
This is not enabled for GLES, and will use the previous blur type.
Test Plan:
Before:
{F6577457}
After:
{F6577458}
Reviewers: #vdg, #kwin, davidedmundson, zzag, fredrik, ngraham
Reviewed By: #vdg, fredrik, ngraham
Subscribers: Codezela, fredrik, abetts, Petross404, rapiteanu, filipf, rooty, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18377
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.
This is something I find unsuited, for the following reasons:
* any test in KWin for functionality set through the plugin would fail
* it's not clear what's going on where
* in worst case some code could deadlock
* KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used
The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.
But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.
To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.
To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.
This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).
As the change could introduce regressions I'm targetting 5.16.
Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18228
Summary:
The new connect syntax has several advantages over the old syntax:
(a) Connecting with the new syntax is faster;
(b) It is compile time checked.
There are still a few places where the old connect syntax is used, e.g.
connecting to QML buttons in the Desktop Grid effect.
Test Plan:
Have been testing this patch for ~2 weeks, haven't noticed any
regressions.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, broulik, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18368
Summary:
Not only does the function windowsShareDesktop become a lot more complex
with the new desktop cardinality comparing if they share any desktop
isn't actually what we want.
If I have 2 windows on desktop 1 and the lower stacked window is also on
desktop 2, when I switch desktops the focus will change, but we don't
want to animate anything here as on this dekstop it has nothing to slide
in front of.
Instead this patch simply checks both windows are on the current
desktop.
Test Plan:
Loaded a few windows. Some on one, some on more.
Before if a window was on desktop 1&2 it wouldn't animate on 2.
Windows now seem to animate when they should and not when they shouldn't.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17943
Summary:
If a window is not on the current virtual desktop, then it won't be
painted/slided. Thus, we can replace EffectWindow::desktop by
EffectsHandler::currentDesktop.
Test Plan: The effect still works correctly on both X11 and Wayland.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17944
Summary:
The idea behind this autotest is to verify that different window
open/close animation effects behave similarly.
Currently, we just check whether Fade/Glide/Scale effect tries to animate
the appearing or the disappearing of toplevels. In the future, the
autotest will be extended to verify that there are no conflicts between
those three effects and the Login/Logout effect, etc.
Test Plan: Ran the test, found a bug in the Fade effect, fixed it.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17526
Summary:
In order to be compatible with the monolithic Fade effect, this effect
animates special windows (e.g. notifications, etc) as well, but some
of those special windows shouldn't be animated by this effect (e.g.
KDE Plasma splash screen).
Test Plan:
Started new Plasma on Wayland session, the KDE Plasma splash screen
smoothly faded out without flickering/blinking, etc.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17209
Summary:
The primary reason for rewriting this effect was to clean up code and
fix spawning of multiple animations for a single window when user cycles
through virtual desktops very quickly.
Visually, the rewritten version doesn't deviate from the old version.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16454
If a full screen effect has been activated, we need to brighten main
windows because the full screen effect can dim windows on its own
(one such effect is the Present Windows, for example).
If the full screen effect is no longer active, we need to dim main
windows back.
Summary:
The ported effect looks quite similar to the C++ version except one
thing: it works correctly when user activates/deactivates a full
screen effect, for example the Desktop Cube effect.
Other than that, there are no behavioral or visual differences.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16452
Summary:
If a window is unminimized and the minimize animation is still active,
don't cancel the latter and start a new animation. Instead, try to
reverse already active animation and if that attempt failed, start a new
animation. This results in more smoother animations.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16451
Summary:
Fade, glide, and scale effect are mutually exclusive effects so they have
to be put into an exclusive group in the desktop effects kcm.
Test Plan: {F6418669}
Reviewers: #kwin, #plasma, #vdg, ngraham, graesslin
Reviewed By: #kwin, #plasma, #vdg, ngraham, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16858
Summary:
Currently, we have three effects that can be used to animate the
appearing of toplevel windows(fade, glide, scale) and one can enable
all three of them, which seems to be wrong. It doesn't make sense to have
glide and scale effect enabled, for example.
We couldn't put all three effects into an exclusive group before because
the fade effect animates not only toplevel windows but also popups. So,
if all three effects are in an exclusive group and you enable glide effect,
for example, then tooltips and other popups won't be faded in/out.
This patch splits the fade effect into two: the first effect (called Fade)
animates toplevel windows and the other one (called Fading Popups) animates
popup windows.
Test Plan:
Have been using the Fading Popups effect in combination with the Scale
effect for a couple of days. Haven't noticed any significant differences between
the new combination (Fading Popups + Scale) and the old combination
(Fade + Scale).
Reviewers: #kwin, #plasma, #vdg, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16836
Summary:
As setDesktop was changed to "move" this left unSetDesktop non-symetric.
This replaces it with explicit API to enter/leave.
This also moves new API to the new object based API rather than still
using ints.
Where numbers are used it has been tidied up so that desktop IDs are
uint, which should be used when we have a list of desktops.
int is used only when we have either a desktop ID or NET::OnAllDesktops
(-1)
Effects API cleared up to use this and use a set of x11 IDs, which
avoids any potential complications of handling add and removes any
ambiguity with what happens if you leave all desktops and such.
Test Plan:
testVirtualDesktops passes (with pending kwayland patch)
Moving a window in the desktop grid on X11 behaves
Moving a window in the desktop grid on wayland behaves
Reviewers: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16704
Summary:
Current code path was attempting to use both framebuffer blit and
glReadPixels on OpenGL ES, instead change the code to use framebuffer
blit and glGetTexImage on OpenGL and glReadPixels on the OpenGLES as it
doesn't have glGetTexImage available.
Test Plan: tested on Nexus 5X.
Reviewers: #kwin, davidedmundson, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T10011
Differential Revision: https://phabricator.kde.org/D16802
