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
Summary:
If you switch virtual desktops while krunner is sliding in, then
depending on whether your distro strips assert statements away,
KWin can crash.
The reason why it crashes is the sliding popups effect tries to unref
deleted windows that it hasn't referenced before (if there is an active
full screen effect, then popups won't be slided out, which in its turn
means that we won't reference deleted windows). So, in the end, the
refcount of those windows can be -1. That triggers an assert statement
in the destructor of the Deleted class, which checks whether the
refcount is equal to 0.
Popups are not slided while there is an active full screen effect because
we don't know what the full screen effect does.
This patch adjusts the sliding popups effect so it stops all active
animations when user switches virtual desktops or when a full screen
effect kicks in. We need to do that so the effect won't try to
unreference windows in postPaintWindow.
Visually, it doesn't look quite nice, but for now that's good enough.
A proper fix would be more complex: we would need to make sure that
full screen effects ignore sliding popups (and also maybe docks) and
perform some input redirection.
BUG: 400170
FIXED-IN: 5.14.4
Test Plan: I'm not able anymore to reproduce bug 400170.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16731
Summary:
On build.kde.org all tests loading scripted effects are failing. This
seems to be because the effects are not installed.
To make this work, this change introduces the following changes:
* scripted effects are copied to ${build}/bin, like all binaries
* the test sets XDG_DATA_DIRS env variable to point to ${build}/bin
This change also needs to be added to further tests once this is
accepted. Furthermore it could be considered whether KPackageLoader
should consider the QCoreApplication::applicationDirPath in addition to
the GenericDataLocation. This would make KPackageLoader work much better
in a build tree only setup.
Test Plan: Test passes locally, obviously not tried on build.kde.org
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16682
Summary:
This patch fixes some of issues that the Snap Helper effect currently
has:
* If a window is being moved, there are visual artifacts (cause: missing
addRepaint's);
* It uses addRepaintFull;
* For some reason, if a window goes deleted, it will be kept around as
long as the Snap Helper effect needs it (visually, it doesn't look
good).
Among other changes:
* Use variables to store color and width of grid lines;
* Use new connect syntax;
* Port to TimeLine;
* Fix coding style in some places.
Test Plan:
Tried the effect with different rendering backends, no longer see visual
artifacts when moving or resizing windows.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15695
Summary: This removes unnecessary duplication.
Test Plan: QtScript doesn't support 'use strict', so the effect still works.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16661
I made a horrible typo("popup" vs "popupWindow"), which went
unnoticeable during code review and while I was testing the ported
effect on Wayland.
Because this change is pretty trivial (fixing a typo), I didn't put it
on review.
Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
If you activate the Present Windows effect and then the Desktop Grid,
you'll be able to see the close button from PW. The reason for that is
PW doesn't destroy the close button and DG doesn't filter it out.
This patch addesses this problem by syncing DesktopGridEffect::isRelevantWithPresentWindows
with PresentWindowsEffect::isSelectableWindow.
On X11, the close button is filtered by the isSpecialWindow check. On
Wayland, the close button is filtered by the acceptsFocus check.
The proposed solution is kinda hack-ish, but on the other hand, we have
to keep those two methods in sync anyway.
In addition to the close button, notifications won't be displayed too.
BUG: 364710
FIXED-IN: 5.14.3
Test Plan:
* Activate the Present Windows effect;
* Activate the Desktop Grid effect;
* (the close button is no longer visible)
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16513
Summary:
Now, when the scripting effects API has all required ingredients to port
the Scale effect to JavaScript we finally can do it.
The main rationale for porting this effect to JavaScript is that
scripted effects API lets us focus more on what we want instead of
"how".
Visually, the ported version doesn't deviate from the C++ version.
Test Plan:
* Enable the Scale effect;
* Open/close a window.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16478
Summary:
When using the natural layout algorithm with the fill-gaps option, a small
error (less than one) is introduced in windows' aspect ratio each time they are
enlarged due to floating-point roundoff.
Currently, the algorithm computes the width and height enlargement factors and
then attempts to enlarge in each of the four possible directions, repeating
until it can't enlarge any windows any further. Hence, this aspect ratio error
can be multiplied by up to four. Especially for small, long, and narrow
windows, this can result in a total error of greater than one by the end of
that loop iteration. If this occurs, on subsequent iterations the height
enlargement factor might then be computed as negative violating some of the
core assumptions of the algorithm and resulting in the loop iterating endlessly
until one of the window dimensions overflows, freezing the program for up to
several minutes.
To fix this, the height enlargement factor should be re-computed based on the
new width each time the window is enlarged, ensuring the error introduced in
the aspect ratio never exceeds one.
BUG: 364709
BUG: 380865
BUG: 368811
FIXED-IN: 5.15.0
Test Plan:
The most reliable way to reproduce the freeze seems to be to activate the
desktop-grid effect while a tool-tip window is fading in.
Ensure desktop-grid is configured to use present windows, and that present
windows is configured to use the natural layout algorithm with the fill gaps
option selected.
The freeze is still intermittent, but using this method should be able to be
triggered within about 10 tries without this fix.
After applying the fix, the freeze has never been observed.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: graesslin, kwin, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16278
Summary:
If user selects a shortcut to trigger the effect, that shortcut won't
work after the KCM is closed because we don't save it.
BUG: 400351
FIXED-IN: 5.14.3
Test Plan:
* Specified custom shortcut to trigger the effect;
* Closed the KCM;
* Pressed the shortcut, a thumbnail appeared.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16456
Summary:
Currently, when the user is moving a window in the desktop grid it is drawn from
the paintScreen function to ensure it appears above all other windows. However,
when drawing the window, the screenProjectionMatrix for the WindowPaintData structure
is never specified. Because of this, the window will not be visible if OpenGL
compositing along with Lanczos scaling are in use since its coordinates will never
be projected into screen-space (unless the window is maximized, in which case the
scaling code is bypassed).
BUG: 361371
BUG: 364509
FIXED-IN: 5.14.3
Test Plan:
Ensure OpenGL compositing is enabled and the scaling method is set to "Accurate" on
hardware supporting this option. Additionally, ensure the desktop grid effect is
active and is configured to use Present Windows. Open a window and ensure is it not
maximized. Click on the window and drag it around - its contents should remain visible
the entire time and follow the mouse.
Reviewers: #kwin, zzag, graesslin, davidedmundson
Reviewed By: #kwin, zzag, davidedmundson
Subscribers: broulik, davidedmundson, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16430
Summary:
Currently, when the user is moving a window in the desktop grid it is drawn from
the paintScreen function to ensure it appears above all other windows. However,
when drawing the window, the screenProjectionMatrix for the WindowPaintData structure
is never specified. Because of this, the window will not be visible if OpenGL
compositing along with Lanczos scaling are in use since its coordinates will never
be projected into screen-space (unless the window is maximized, in which case the
scaling code is bypassed).
BUG: 361371
BUG: 364509
FIXED-IN: 5.14.3
Test Plan:
Ensure OpenGL compositing is enabled and the scaling method is set to "Accurate" on
hardware supporting this option. Additionally, ensure the desktop grid effect is
active and is configured to use Present Windows. Open a window and ensure is it not
maximized. Click on the window and drag it around - its contents should remain visible
the entire time and follow the mouse.
Reviewers: #kwin, zzag, graesslin, davidedmundson
Reviewed By: #kwin, zzag, davidedmundson
Subscribers: broulik, davidedmundson, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16430
Summary:
There were several reasons to rewrite the Minimize Animation effect in
JavaScript: to simplify code and to get rid of full repaints. One could
say that nothing prevents us from calculating the dirty region in
postPaintScreen or postPaintWindow and it is correct, but with the
scripting effects API the dirty region will be calculated for us, so we
can focus more on "what we want" instead of "how".
Visually, the "old" effect and the rewritten one look quite the same.
Except one tiny bit: if a window doesn't have an icon in the task manager,
it won't be animated. The reason for that is the purpose of this effect is
to show where the window will be after it's minimized, if the window
doesn't have icon in the task manager, one can't click at the center of
the screen to unminimize the window.
There is one significant change, the name of the effect was changed to
"Squash". If we put this effect and the Magic lamp effect under "Window
Minimize Animation" category (or if we add some "heading" label), then
the old name and the name of the category would "conflict". The new name
was suggested by Nate Graham and it very closely describes what the
effect does. "Scale" doesn't fit this effect because while a window is
being animated, its aspect ratio is not preserved.
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16372
Summary:
Background behind some windows is not blurred because the invert effect
sets PAINT_WINDOW_TRANSFORMED. This essentially "turns off" the blur and
the background contrast effect unless we set the force roles.
Because the invert effect is a "post-processing"(not really) effect we
don't have to set that flag.
BUG: 279076
BUG: 359583
FIXED-IN: 5.14.3
Test Plan: {F6341916}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16358
Summary:
For some historical reasons, the sheet effect uses animation duration of
500ms. In comparison to other effects that animate the appearing and the
disappearing of windows, 500ms is too high value for the duration.
As the title says, this change decreases the default animation duration
to 300ms. The new duration is more saner.
The opacity is animated to make the effect look smoother with the
shorter animation duration.
BUG: 400021
FIXED-IN: 5.15.0
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16359
Summary:
When using the natural layout algorithm with the fill-gaps option, a small
error (less than one) is introduced in windows' aspect ratio each time they are
enlarged due to floating-point roundoff.
Currently, the algorithm computes the width and height enlargement factors and
then attempts to enlarge in each of the four possible directions, repeating
until it can't enlarge any windows any further. Hence, this aspect ratio error
can be multiplied by up to four. Especially for small, long, and narrow
windows, this can result in a total error of greater than one by the end of
that loop iteration. If this occurs, on subsequent iterations the height
enlargement factor might then be computed as negative violating some of the
core assumptions of the algorithm and resulting in the loop iterating endlessly
until one of the window dimensions overflows, freezing the program for up to
several minutes.
To fix this, the height enlargement factor should be re-computed based on the
new width each time the window is enlarged, ensuring the error introduced in
the aspect ratio never exceeds one.
BUG: 364709
BUG: 380865
BUG: 368811
FIXED-IN: 5.15.0
Test Plan:
The most reliable way to reproduce the freeze seems to be to activate the
desktop-grid effect while a tool-tip window is fading in.
Ensure desktop-grid is configured to use present windows, and that present
windows is configured to use the natural layout algorithm with the fill gaps
option selected.
The freeze is still intermittent, but using this method should be able to be
triggered within about 10 tries without this fix.
After applying the fix, the freeze has never been observed.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: graesslin, kwin, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16278
Summary:
There is no concept of managed windows in Wayland, so every time we call
managed() on a Wayland client, it will return false.
This change addresses that problem by invoking managed() only for X11 clients.
CCBUG: 398100
Test Plan:
* Open KCM of the Translucency effect and decrease opacity of inactive windows;
* Open Dolphin;
* Click on desktop.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16319
Summary:
There is no concept of managed windows in Wayland, so every time we call
managed() on a Wayland client, it will return false. We need to call
that method only for X11 clients.
The resource name part for authentication agents is empty because
KWayland can't get their executable paths.
CCBUG: 398100
Test Plan:
Before:
{F6338545}
After:
{F6338546}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16317
Summary:
There is no concept of managed windows in Wayland, so every time we call
managed() on a Wayland client, it will return false.
This change addresses that problem by invoking managed() only for X11 clients.
CCBUG: 398100
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16312
Summary:
In some cases, the out transition is false-triggered because we don't
react to changes in the keep-above and the full screen state.
Test Plan:
* Set the keep-above state on a window;
* Click on the desktop;
* (the window didn't "flicker")
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16270
Summary: Do the same what we do on X11.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16271
Summary:
Such an option would be useful for people that are used to watch videos
in the fullscreen mode.
By default, we still dim fullscreen windows because watching videos in
fullscreen mode is not the only one use-case. One could have a text
editor in fullscreen mode on one screen and Konsole on another screen.
In that case, it would be desired to dim the text editor if the latter
is active. Also, because we don't have stats of how the fullscreen mode
is used by KDE Plasma users.
BUG: 399822
FIXED-IN: 5.15.0
Test Plan:
* Unchecked the "Fullscreen windows" checkbox;
* Opened Konsole;
* Opened Firefox in the fullscreen mode;
* Pressed Alt+Tab;
* (Firefox stayed bright)
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16216
Summary:
The Dim Inactive effect expects that the windowClosed signal always
proceeds the windowDeleted signal. But in some cases that's not the case.
If a window gets destroyed before becoming ready for painting, only
the windowDeleted signal will be emitted. In addition to that, KWin will
activate that window, which means we'll probably start a transition for
it.
Because this effect cannot terminate active transitions for such
windows, KWin can crash in postPaintScreen.
This change addresses the crash in postPaintScreen by adding extra clean
up stuff in the windowDeleted slot to make sure that there are no
transitions for deleted windows.
The proper fix would be to not emit windowActivated signal for windows
that are not ready for painting.
BUG: 399612
FIXED-IN: 5.14.1
Test Plan:
Ran
```
x <- seq(5, 15, length=1000)
y <- dnorm(x, mean=10, sd=3)
plot(x, y, type="l", lwd=1)
```
in RKWard multiple times.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16130
Summary:
In order to check whether a window is on some particular virtual
desktop, one has to use isOnDesktop.
Also, this change adds implicit support for the new virtual desktop protocol.
Test Plan:
Switched between virtual desktops with a Konsole window being on all
desktops.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16103
Summary:
If a window was moved to another virtual desktop, then it would be faded
in. The desired behavior is to not animate it at all.
Test Plan: Moved a Konsole window between virtual desktops, it stayed opaque.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16102
Summary:
If a modal window is closed and some alternative effect that animates
the disappearing of windows is enabled(e.g. the Glide effect, or the
Scale effect), the Dialog Parent effect can cause flickering of the
parent window because its animation duration doesn't match duration of
those alternative effects.
Also, if the Fade effect, the Glide effect, and the Scale effect are
disabled, the Dialog Parent will keep the parent window alive for no
good reason.
This change addresses that problem by adding keepAlive property to
`animate` function so scripted effects have more control over lifetime
of animated windows.
If both a modal window and its parent window are closed at the same time
(and there is no effect that animates the disappearing of windows), the
Dialog Parent will stop immediately(because windowDeleted will be
emitted right after windowClosed signal).
If both a modal window and its parent window are closed at the same time
(and there is effect that animates the disappearing of windows), the
Dialog Parent won't reference the latter window. Thus, it won't cause
flickering. I.e. it will "passively" animate parent windows.
BUG: 355036
FIXED-IN: 5.15.0
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14919
Summary:
This lets other effects know whether they should inhibit or not which
reduces
visual glitches of overlapping animations.
BUG: 321201
FIXED-IN: 5.15.0
Test Plan: Switched desktops, they still faded
Reviewers: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15474
Summary:
If one wants to drag a maximized window while he or she has enabled both
the Wobbly Windows and the Maximize effect, visual artifacts can be
shown.
When the Maximize effect animates transition from maximize to restore,
some parts of the window can overshoot repaint regions(because of
wobbliness), leaving us with the visual artifacts.
To fix that, we have to take into account current scale and translation
when calculating dirty region in the Wobbly Windows effect.
BUG: 370612
FIXED-IN: 5.14.1
Test Plan: When dragging maximized windows, there are no visual artifacts anymore.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15961
Summary:
The Scale effect and the Glide effect have to animate only ordinary
windows(i.e. the ones that are considered to be apps).
On X11, in order to distinguish ordinary windows from combo box popups,
popup menus, and other popups, those effects check whether given window
is managed.
On Wayland, there is no concept of managed/unmanaged windows.
XDG Shell protocol defines 2 surface roles:
* xdg_toplevel;
* and, xdg_popup.
The former can be used to implement typical windows, the ones that can
be minimized, maximized, etc.
The latter can be used to implement tooltips, popup menus, etc. Thus,
that's a good criteria to filter popup windows.
CCBUG: 398100
Reviewers: #kwin, graesslin, davidedmundson
Reviewed By: #kwin, graesslin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15117
Summary:
If a window is being slided in and for some reason it gets closed, the
window will be slided out. The problem is that there is a jump between
the slide in animation and the slide out animation.
The reason for that is we cancel the slide in animation when the slide
out animation is started.
It makes sense to cancel previously active animations because they have
different durations. But visually, it doesn't look good.
TimeLine tries to preserve progress value when changing duration. Thus,
let's utilize that to fix the jump.
This change matters only with animation speed factor > 1.0.
CCBUG: 264276
Test Plan: Manually.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15626
Summary:
With the Oxygen cursor theme, a visual glitch can appear in the
bottom-left corner of the cursor when the screen is zoomed in.
The reason for that is we're using GL_REPEAT for GL_TEXTURE_WRAP_S
and GL_TEXTURE_WRAP_T. So, when the linear filter samples neighboring
texels in the bottom, it can sample some texels from the top (because of
GL_REPEAT).
To fix that, we have to set the wrap mode to GL_CLAMP_TO_EDGE.
BUG: 338254
FIXED-IN: 5.14.0
Test Plan:
Before:
{F6303912}
After:
{F6303913}
Tried other cursor themes(Breeze and Adwaita), everything looks okay.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15949
Summary:
This means that if one opens/closes a window whilst present windows (for
example) is active we don't have two effects meddling with the opacity.
Like glide and scale this disables if it's invoked during an active full
screen effect, but it does not cancel animations that are running when a
full screen effect is launched.
Test Plan:
Windows still fade normally as before
Ran sleep ; dolphin with present windows / cube
Present windows fades windows itself so it's hard to see any difference
But it's more technically correct
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15933
Summary:
The "Force" part in WindowForceBackgroundContrastRole and WindowForceBlurRole
is confusing. If WindowForceBlurRole is set on a window, background
behind it won't be blurred.
By setting WindowForceBlurRole we tell the Blur effect "that's fine to
do your business behind transformed windows."
The Slide effect only translates windows, it doesn't distort them, etc.
So, we can set WindowForceBackgroundContrastRole and WindowForceBlurRole
for all windows.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15707
Summary:
Full window repaints issued by the Sliding Popups effect can hide bugs in
other effects that animate the disappearing of windows (e.g. Scale).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15822
Summary:
If isActive() returns false, neither paintScreen nor paintWindow nor
postPaintScreen will be called.
So, `if (m_active)` checks are redundant.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15708
Summary:
The Show Paint effect is useful when debugging repaint regions issued by
effects. The only headache with it is necessity to enable/disable it.
Consider the following workflow:
* Do some change to an effect;
* Compile KWin (or the effect);
* Go to System Settings and enable the Show Paint effect;
* Test effect, check repaint regions, etc;
* Disable the Show Paint effect;
* Go to the step 1.
This workflow is really exhausting. Also, when testing repaints in a
nested compositor, things become quite messy.
Because purpose of this effect is to debug repaints (and because this
effect is not meant for daily usage), I think that's fine to change
how it's activated.
This patch improves the workflow by changing the way how this effect
gets activated. Instead of enabling/disabling it, one can just use a shortcut
to activate or deactivate the effect.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: broulik, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15703
Summary: This is second part of {D15175}, and aimed at fixing Bug 390366.
The problem was that effect relied on isManaged() to detect OSDs and notifications, that should be painted on top of the cube. On Wayland, the desktop window itself is not managed, which made it "sticky".
Instead we use isSpecialWindow() check to explicitly make notifications and OSDs sticky.
It still requires fixing Plasma::Dialog, since it does not set isSpecialWindow() flag correctly.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15496
BUG: 390366
FIXED-IN: 5.15.0
Summary:
Bugs occurred because KWin was not very happy when windows were painted during CubeSlideEffect::paintScreen().
Another issue is that blur, although it was supposed to, did not work at all (haven't found appropriate bug on bugzilla).
As well as background contrast effect.
This patch does the following thing:
- Adopted WindowForceBlur / WindowForceBackgroundContrast logic from SlideEffect, instead of panels/stickyWindows QSets (those become useless anyway)
- Added shouldAnimate code, which determines whether a window should be animated with the cube (i.e. ordinary windows) or should stick (i.e. panels or pinned windows, if corresponding options are checked in the settings)
- It paints an additional non-transformed screen, on which it paints only "sticky" windows. This is done because otherwise KWin would apply blur not behind the OSD, but on the same place on moving cube face.
- (in addition) switched to new Qt5 connect syntax.
Reviewers: #kwin, zzag
Differential Revision: https://phabricator.kde.org/D15175
BUG: 361516
BUG: 362360
FIXED-IN: 5.15.0
Summary:
An opacity animation calls multiplyOpacity not setOpacity, therefore we
want to always fade between 0 and 1, not up to the window opacity.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15476
Summary:
The Track Mouse effect can be toggled either by pressing modifier keys
and moving mouse or by pressing a shortcut. It's not possible to use
the latter and then the former without changing config.
But there is one caveat, in order to use shortcut, you have to uncheck
all modifier keys. This seems to be not very intuitive.
In addition to that, the KCM allows to change shortcut even if there is
some checked modifier.
As the title says, this change makes possible to use both modifier keys
and shortcut to activate this effect without changing config.
KCM:
{F6237308, layout=center, size=full}
BUG: 398124
FIXED-IN: 5.14.0
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: broulik, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15272
Summary:
Summary of changes:
* Use QVector to store colors
* Add Q_OBJECT macro
* Port away from QRegion::rects
* Fix coding style
* Use default member initialization
* Use nullptr
* Reserve rects in paintXrender
The behavior of this effect haven't been changed, it still acts as before.
Test Plan: Compiles, and the Show Paint effect is still a psychedelic thing.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15424
