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:
So far KWin did not re-evaluate the window rules when the Client's
window class changes. Window class is the main (static) feature the rule
selection is based on. For dynamic changing mapping features like caption
KWin does re-evaluate the rules.
The reason for KWin to not evaluate when the class changes is that KWin
expects the class not to change. From ICCCM section 4.1.2.5:
> This property must be present when the window leaves the Withdrawn
> state and may be changed only while the window is in the Withdrawn
> state. Window managers may examine the property only when they start
> up and when the window leaves the Withdrawn state, but there should be
> no need for a client to change its state dynamically.
Unfortunately there are prominent applications such as Spotify which
violate this rule and do change the window class dynamically. While this
is a clear ICCCM violation there is nothing which really forbids it (may
not != must not) and nothing which forbids KWin to react on changes.
As also libtaskmanager started to react on it, it makes sense to also
hook up the required bits for window rules. After all KWin detects
changes to the window class for some time already and has the
functionality to evaluate the rules. So all there is, is one connect
which improves the situation for our users, while at the same time it
should be rather risk free. If a setup window rule breaks after this
change it's due to the client not being ICCCM compliant.
Test Plan:
I don't use any of the affected applications, so it's only
tested with the new added unit test.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16670
Summary:
Without pretendingn to activate the Window, Qt will not send
the right signals for accessibility, thus screen readers not working.
Reviewers: kwin, davidedmundson
Reviewed By: davidedmundson
Subscribers: graesslin, davidedmundson
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16664
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
Summary:
Ideally KWin would not depend on private headers... but at least we can
remove unused ones.
Test Plan: still builds, I don't see anything requiring the header.
Reviewers: zzag
Reviewed By: zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16655
Summary: This file was required for Qt 5.8. We require 5.11 as minimum version.
Test Plan: Grepped for the file being used in other cmake code, rebuilt KWin without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16654
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:
AbstractClient::mainClients is quite generic, it can return either
transientFor parent or group member parents.
Test Plan: Existing tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16586
Summary:
This change brings improved num lock support to KWin. The modifier state
is read and also mapped to Qt::KeyboardModifiers. Furthermore the input
config is read and the NumLock key is evaluated. If the requested state
does not match the current num lock state the state is swapped.
BUG: 375708
FIXED-IN: 5.15
Test Plan: New unit test added, no manual test due to lack of hardware
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16428
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:
862bf0f153 introduced a regression(sorry
for that): if you close a confirmation dialog(with the Scale effect and the
Dialog Parent effect being enabled), the main window(s) will flicker.
That flickering happens because the C++ version of the Scale effect and
AnimationEffect unref deleted windows in different places. AnimationEffect
unrefs deleted windows in prePaintScreen, which btw is not the best
place to do that. The C++ version unrefed windows in postPaintScreen.
So, when the Scale effect has finished animating the main windows, it
will unref them, but windowDeleted signal won't be emitted immediately.
Which means that the Dialog Parent won't be able to delete corresponding
animations on its side and main windows will be painted for a single
frame.
This change addresses flickering by adjusting prePaintWindow in
AnimationEffect so deleted windows won't be painted if none of
animations keeps them alive.
Test Plan:
(make sure that both the scale and the dialog parent effect are enabled)
* Go to System Settings > Application Style > Window Decorations;
* Select a decoration that is different from the current;
* Close the system settings window (don't click "Apply" button);
* When a dialog is shown, click "Discard" or "Apply" button.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16542
Summary:
All other KCMs have their {nav Get New [things]...} buttons in the bottom-right corner. This patch adjusts KWin's KCMs to adopt the same convention there too.
With this patch, all KCMs will have their GHNS buttons in the same location.
Closes T9954
Test Plan:
{F6375278}
{F6375277}
{F6375276}
{F6375275}
Reviewers: #kwin, #vdg, zzag
Reviewed By: #kwin, zzag
Subscribers: Codezela, kwin, kde-doc-english
Tags: #kwin, #documentation
Maniphest Tasks: T9954
Differential Revision: https://phabricator.kde.org/D16537
Summary:
The switch statements iterated over all possible enum values.
When a new enum value is added, it will generate a compiler warning this way.
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16480
Summary:
KGlobalAcceld stores actions grouped by ID and a single display name.
When an action with a given id changes, the display names change for all
actions in that
group.
The KCM sets the ID to "kwin" but does not explicitly set a display
name. This means it is automatically deduced which will be kcmshell or
systemsettings.
The end result is all kwin shortcuts get renamed in system setting's
global shortcuts UI until kwin is restarted.
This patch explicitly sets the dispay name.
BUG: 400248
Fixed-in: 5.15.0
Test Plan:
Changed virtual desktops
Checked global shortcut settings still listed kwin as kwin
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16418
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:
Some JavaScript based effects need to grab particular windows in order
to avoid conflicts with other effects.
Example usage:
```lang=js
effects.windowAdded.connect(function (window) {
if (effect.grab(window, Effect.WindowAddedGrabRole)) {
window.coolWindowTypeAnimation = animate({
...
});
}
});
```
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, graesslin, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13153
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:
Plasma's OSDs for volume/screens etc use PlasmaExtras.Heading, this
should to.
Also correct centering text to constrain the text element and align the
text within that bounding box. Previous code could have overflown in the
event of a really really long desktop name if we're resizing to the
grid.
BUG: 356600
Test Plan:
Switched desktop with OSD on
Tried with and without "show desktop layout indicators"
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16420
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
