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
