Summary:
Check that the Sliding Popups effect grabs windows no matter in what
order it and the Scale effect are loaded.
Test Plan: Ran the test.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15729
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:
Getter is exposed as a property on scripted effect in a way that hides
pointers from the scripting side.
Setter is implicitly handled as a property of newly created animations
and holds the activeFullScreenEffect whilst any of them are active. Like
existing effects it remains up to the effect author to avoid the
problems of multiple full screen effects. The RAII lock pattern is
somewhat overkill currently, but it's the direction I hope we can take
EffectsHandler in next API break.
BUG: 396790
--
This patch is against the QJSEngine port, though it's not conceptually a
requirement.
Test Plan: Unit test
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14688
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:
Currently, if one wants to install a scripted effect from the KDE Store,
the effect won't show up in the Desktop Effects KCM. The reason for that
is kpackagetool5 doesn't know where to install effects (they have to be
installed under ${DATA_DIR}/kwin/effects).
Another problem is that even if the scripted effect is installed in the
right directory (e.g. ~/.local/share/kwin/effects), it won't be listed in
the Desktop Effects KCM because it doesn't have a desktop file in
kservices5 dir. Please notice that the effect will be "visible" for KWin, i.e.
you can enable it by editing kwinrc.
This diff addresses those 2 problems by:
* Adding a PackageStructure plugin for effects (so they are installed
under kwin/effects/);
* Using KPackage::PackageLoader to get list of scripted effect in the
Desktop Effects KCM.
Test Plan:
* Installed an effect from the KDE Store, it appeared in the Desktop Effects
KCM;
* Removed it.
Reviewers: #kwin, mart, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: ngraham, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15372
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:
QSignalSpy is not happy about KWin::Deleted*:
QWARN : SlidingPopupsTest::testWithOtherEffectWayland(wobblywindows, slide)
QSignalSpy: Unable to handle parameter 'deleted' of type 'KWin::Deleted*' of
method 'windowClosed', use qRegisterMetaType to register it.
Test Plan: Ran the test, haven't noticed any warnings.
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15730
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:
Add a debug format for ShellClients, otherwise the output is always
empty. Also add the nospace qualifier to ShellClient's and Client's
debug output to present it correctly.
Test Plan: Manually.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15560
Test Plan:
Compiled latest GTK
Ran gtk4-demo and used WAYLAND_DEBUG to confirm it used the correct
shell
tested a top level and a popup
Reviewers: #plasma, romangg
Reviewed By: #plasma, romangg
Subscribers: romangg, mart, graesslin, zzag, kwin
Tags: #kwin
BUG: 398614
FIXED-IN: 5.15.0
Differential Revision: https://phabricator.kde.org/D13530
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:
kwin_wayland now automatically chooses an appropriate backend, such as
DRM, nested wayland or nested X. If nested it will automatically go into
windowed mode regardless of whether --windowed is set and works fine.
Backend choosing logic existed duplicated in older code for kwin_wayland
--windowed, with the subtle unexpected difference that it preferred
running as an X client over running as a wayland cient if both are
present. This simplifies codes and syncs automatic resolution behaviour.
kwin_wayland --windowed with --x11-display or --wayland-display will
remain the same.
Test Plan:
Ran kwin_wayland with and without --windowed inside another wayland.
Got the same backend chosen
Tested that kwin_wayland (without --windowed) on an X machine worked just fine.
Reviewers: #kwin, mart
Reviewed By: #kwin, mart
Subscribers: mart, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13658
Summary:
Qt render loops behave quite differently to each other.
KWin scripting as a workaround for another situation cleans
(17553e5a1f) handles tracking of script
windows by deleting the underlying window handle on hide.
This currently happens before the window gets the hideEvent.
Arguably this is a quirk with Qt, but in the current state:
- QSGThreadedRenderLoop deletes the platform window and cleans up
- We then get the hide() event. This no-ops because there's no window.
(else branch of case WM_TryRelease in qsgthreadedrenderloop.cpp)
- We carry on rendering animations despite having no platform
- undefined behaviour
Normally this isn't a problem as typically destruction of the platform window
happens only when a window is being deleted, we're messing with Qt
internals here.
If we make sure the QHideEvent is processed by the render loop first,
things seem fine.
BUG: 397767
Test Plan:
Ran QSG_RENDER_LOOP=threaded
Read output with scenegraph logging rules on
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15025
Summary:
With 2694839099, 0bd5eff862 and f0ba436c72 it is now possible to
unconstrain a pointer by killing the client or deactivating the window, for
example by switching the window via the TabBox.
A user should always be able to do it therefore without needing to explicitly
break the pointer constrain as in the past with the Esc key.
Therefore remove the functionality and also remove the OSD announcing it,
which was often shown at the wrong time.
Test Plan: Manually and auto test adapted.
Reviewers: #kwin, #vdg, hein
Reviewed By: hein
Subscribers: ngraham, hein, kwin
Tags: #kwin
Maniphest Tasks: T8923
Differential Revision: https://phabricator.kde.org/D15234
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
