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
Summary:
The desktop file parser supports only QString, QStringList, Int, Double,
and Bool. QUrl is not a supported type for some reason.
Thus, let's use QString for X-KWin-Video-Url.
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: Zren, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15373
Summary:
Modification of undeclared variables is illegal in the strict mode, e.g.
```lang=js
mainWindows = window.mainWindows();
```
is illegal.
Test Plan: The Dialog Parent effect works with both QScriptEngine and QJSEngine.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15413
Summary:
The x-coordinate of the area's left edge and y-coordinate of the area's
top edge are adjusted by 1px leading to a gap between the frame and
magnified area. Because area has type of QRect, we have to adjust only
coordinates of the right and bottom edge by 1 px.
Because QRectF::right() == QRectF::x() + QRectF::width(), we can use
QRectF, which leads to more cleaner code because we don't need to do 1px
adjustments.
Test Plan:
Before:
{F6235388, layout=center, size=full}
After:
{F6235439, layout=center, size=full}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15275
Summary:
* effects.h includes client.h and forward declares Client, both at the
same time. Thus, delete the include;
* the blur effect includes effects.h. That, most likely, is a leftover
after 3f5bf65a9e.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15191
Summary:
While BuiltInEffects has effectData() function, many functions repeat
s_effectData.at(index(effect)), which is what effectData() is doing.
By using effectData(), we'll get rid of those repetitions and maybe make
easier transition to other underlying data structure that stores metadata
for builtin effects.
Test Plan: Compiles, all enabled builtin effects are loaded and working.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13587
(cherry picked from commit 7bfaa6e913)
Summary:
The Dim Inactive effect sees the world a little bit differently.
m_activeWindow is currently active window that can be dimmed later on.
In most cases, it's the same as effects->activeWindow(). In rare cases,
it can be nullptr, even when effects->activeWindow() is not equal to nullptr
(e.g. when active window is a context menu popup).
canDimWindow is a helper that returns true if a given window should be
dimmed, otherwise it returns false. It has one special case: if a given
window is equal to m_activeWindow, return false. I.e. don't dim active
windows.
Currently, if user changes config of this effect, active window becomes
dimmed.
The reason for that is we hit that special case when deciding whether
effects->activeWindow() should be m_activeWindow.
This change addresses that problem by resetting m_activeWindow so we
don't hit that special case.
Test Plan:
* Opened KCM of this effect;
* Changed strength;
* (the KCM window stayed bright after I clicked "Apply" button).
(everything else works as expected)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14973
Summary:
The Dim Inactive effect was rewritten mostly to fix most of issues with
it, e.g. after leaving a full screen effect(e.g. Desktop Grid) windows
sometimes are not dimmed back, or when a window becomes inactive there
is no smooth transition, etc.
{F5956124}
//Before: the window is not smoothly dimmed.//
{F5956127}
//After: the window is smoothly dimmed.//
In combination with an effect that animates the disappearing of windows,
e.g. Glide, the rewritten Dim Inactive effect doesn't "flash" windows.
If an active window has been closed, it will stay bright. If an inactive
window has been closed, it will stay dimmed.
Among other changes, the KCM has been re-designed to follow common KCM
design in Plasma:
{F5956128, layout=center, size=full}
The way the rewritten Dim Inactive effect handles flashing/flickering problem can be
reused in the Dialog Parent effect.
### Demo
{F5959885}
//Before: dimming of a window group.//
{F5959886}
//After: Dimming of a window group.//
Depends on D13740
CCBUG: 359251
Test Plan:
Test plan #1
* Activated the Desktop Grid effect
* Dimmed windows smoothly brightened
* Left desktop grid
* Windows dimmed back
Test plan #2
* Opened Dolphin and its Preferences window
* Clicked on desktop, both Dolphin and the Preferences window dimmed
* Clicked on Dolphin, both windows smoothly brightened back
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: davidedmundson, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13720
l10n daemon script