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:
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:
If the Desktop Grid effect doesn't use the Present Windows effect to
layout windows, windowAt helper can return a window that doesn't belong
to current activity because it doesn't check whether that window belongs
to current activity.
This change addresses that problem by adding corresponding check.
BUG: 301447
FIXED-IN: 5.13.4
Test Plan:
//Unchecked "Use Present Windows effect to layout the windows".//
* Switched to activity #1
* Switched to virtual desktop #1
* Launched Konsole and maximized it(to increate hit area)
* Switched to activity #2
* Switched to virtual desktop #2
* Launched Dolphin and maximized it
* Activated the Desktop Grid effect, clicked on virtual desktop #1 (activity #2 is still active)
* Switched to activity #1
* Activated the Desktop Grid effect, clicked on virtual desktop #2 (activity #1 is still active)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14046
Summary:
Currently, effects like Maximize, Slide Back have problems with setting
WindowForceBlurRole. They store previous state of WindowForceBlurRole.
This is wrong. Instead they should either ignore previous state of
WindowForceBlur or refcount forced role.
There's no need for refcounting right now. For example, if several effects
force blur or background contrast, they are most likely in a conflict.
Please notice that the Desktop Grid effect uses the Present Windows
effect only to calculate transformations.
Some other problems with the code that sets WindowForceBlurRole:
* Maximize effect stores previous state of WindowForceBlurRole only
for one window. It ignores the fact that there could be several
active maximize animations;
* Desktop Grid/Present Windows/Slide back don't clean after themselves.
So, after using those effects for good amount of times, memory usage
will bump.
Test Plan:
* Enabled blur for Konsole
* Maximized Konsole
* Activated Present Windows
* Activated Desktop Grid
* Raised another window(to trigger Slide Back)
Reviewers: #kwin, fredrik
Reviewed By: fredrik
Subscribers: fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13479
Summary:
Apparently some old configs made PresentWindows register the top left
corner which does not make any sense as that's not supported by touch.
So to be sure, don't register those edges.
BUG: 383797
FIXED-IN: 5.11
Test Plan: Not tested, I'm on Wayland
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7508
Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
Summary:
All effects which use a (pointer) screen edge now also support the touch
screen edges. These are:
* Cube (cylinder, sphere)
* DesktopGrid
* PresentWindows (current, all, class)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5269
Summary:
This change adds global touchpad swipe gestures to the
GlobalShortcutsManager and hooks up the swipe gestures as defined at the
Plasma Affenfels sprint:
* swipe up: Desktop Grid
* swipe down: Present Windows
* swipe left: previous virtual desktop
* swipe right: next virtual desktop
The main work is handled by two new classes: SwipeGesture and
GestureRecognizer. This is implemented in a way that it can be extended
to also recognize touch screen gestures and pinch gestures.
The SwipeGesture defines what is required for the gesture to trigger.
Currently this includes the minimum and maximum number of fingers
participating in the gesture and the direction. The gesture gets
registered in the GestureRecognizer.
The events for the gesture are fed into the GestureRecognizer. It
evaluates which gestures could trigger and tracks them for every update
of the gesture. In the process of the gesture tracking the
GestureRecognizer emits signals on the Gesture:
* started: when the Gesture gets considered for a sequence
* cancelled: the Gesture no longer matches the sequence
* triggered: the sequence ended and the Gesture still matches
The remaining changes are related to hook up the existing shortcut
framework with the new touchpad gestures. The GlobalShortcutManager
gained support for it, InputRedirection and EffectsHandler offer methods
to register a QAction. VirtualDesktopManager, PresentWindows and
DesktopGrid are adjusted to support the gesture.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5097
Summary:
The DesktopNameAlignment was once set through the kcfg generated file
and once manually. We don't need the manual double save.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3340
Summary:
Desktop Grid has a feature that right or middle clicking a window toggles
the on all desktop state. If that is done for a desktop window, things
obviously start to fail.
KWin internally allows to change virtual desktop for all windows, even
for windows like the desktop or docks. Changing in KWin core is not a
solution.
Thus a special casing in desktop grid is added to disallow the selection
for desktop windows.
BUG: 372037
FIXED-IN: 5.8.4
Test Plan: Tried right clicking desktop window and other windows.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3253
Summary:
This reverts commit 14d1fdf63f.
The zoom effect is definitely the wrong way, it's broken (can be
triggered without moving the mouse, expands windows outside of their
allotted area (looks like broken sizing/placement), isn't animated so
feels very choppy, isn't using well-known highlight semantics), the
result is that it feels unnatural and jarring. To be honest, when I
looked at it, I was looking for a bug in the code, e.g. margins not
being taken into account. It didn't come up in me that this could be
wanted behavior, until I read the code.
As to the original commit message: The highlight is useless for this
case, as any window can be dragged or activated, highlighted or not.
What *could* work is to somehow intensify the colors, but that again
would have to be animated, and play well with the ongoing desktop-zoom
animation, the mouse pointer location changes relative to the window, so
it's really complex to get right. I thought of this for a while, I don't
think the complexity that has to be implemented is worth the benefit,
because, what does highlighted really mean here? "window is under the
mouse" isn't a useful metric, as we don't know if the user is changing
desktops or rearranging windows, and "window under mouse" changes
depending on the zoom level, "window can be dragged or activated" also
isn't a useful metric, as I can do that with any window, anyway.
Test Plan: Tested with patch applied, desktopgrid windows don't jump around anymore.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1209
Most of those effects didn't need special screen locking handling on
X11 as they prevented screen locking. On Wayland though, we don't
want the lock screen shown on a cube.
REVIEW: 126122
Eg. if a window is closed while "timeline.currentValue() == 0",
slotWindowClosed() will shortcut exit and not be removed from the
managers, thus dangle around forever.
Maybe there're other ways for a window to be deleted w/o
the closed slot being entered.
CCBUG: 339970
REVIEW: 126034
While the main plasma desktop containment does one
desktop per screen, that does not necessarily hold
for other containments, let alone other desktop shells
To indicate that the window is "active" ie. can
be dragged or activated (like in present windows)
There was either a bug or a forum post complaining
about the inability to activate windows from DG
They're only traversed and QHash is unordered - so
the worst container. Also we have complete control
over the maintained class, so we can just keep the
mapped EffectWindow there
esp. the list-remove icon looks like "delete" and
can cause worries about what happens to the windows
as a bonus, the buttons now follow the DPI. are a
little smaller (presently might fit touch devices? but
is way to huge on "normal" desktops with ordinary DPI)
and the buttons have nice visible animations on pressing
BUG: 354131
FIXED-IN: 5.5
before, hiding the buttons relied on the effect
seeing a paint event for the (with a low timeline
value) what's too wonky at least for instant animations
(certain failure) or when effect exits immediatey
(due to screen edge invocation issues or whatever)
BUG: 351869
FIXED-IN: 5.4.2
REVIEW: 124970
Theory:
----------
because PresentWindowsEffect::screenCountChanged() is shortcut
for "if (!isActive())", but the desktopgrid doesn't call
PresentWindowsEffect::setActive (or at least
PresentWindowsEffect::screenCountChanged), so the effect can
"miss" the increasing screen count change (it sees the signal,
but ignores it) and when desktopgrid calls it, it assumes the
m_gridSizes array is big enough (but it isn't)
Steps:
----------
1. effects are loaded, 1 screen present
2. 2nd screen gets added, but inactive effects ignore that
3. desktop grid gets activated, updates according to screen count,
calls presentwindows for screen #2
4. presentwindows data is only prepared for one screen from step 1
=> BOOM
BUG: 351724
CCBUG: 326032
FIXED-IN: 5.4.2
REVIEW: 124960
the (old) button effect windows used to be unreferenced
with the re-invocation of the effect. because we stopped
deleting/recreating the window, this approach failed and
the effect window was never deleted.
Unreferencing the window at proper occasion (see new hide
location) coked up - guess what - the exact same "texture is
junk" issue as for the QtQuick close button in present windows...
So we resort to the exact same stupid "hide by moving" solution
as we have there.
BUG: 348577
FIXED-IN: 5.4
REVIEW: 124136
Without the componentDisplayName the shortcut dialog takes the name of
the application e.g. Systemsettings or "KDE Control Module", but we want
it to be KWin.
REVIEW: 124706
Same issue as with present windows closers: qml is slow
Interestingly "hide" means "hide" here and there're also
no visual artifacts.
BUG: 347339
REVIEW: 123668
This is now crucial, because while before
(the minimized) windows were conditionally
shown, but are now always behind the desktop.
Also, it makes the tabbox more consistent.
BUG: 344083
REVIEW: 122679
