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
DesktopGrid uses PresentWindows Effect as a proxy effect. Instead of
hard coding the name of the Effect let's use the name resolving provided
by BuiltInEffects.
This removes all the hacks to add kwin4_effect_ to the name of the Effect
and adjusts the desktop files of the effect configuration's parent
component.
Note: the scripted effects still start with kwin4_effect_ prefix.
REVIEW: 117367
All KCMs and KWin core use the BuiltInEffects namespace to find and
interact with the effects. There is no information left in the desktop
file which are of usage. Thus they can be removed.
