Summary:
Apparently this test is flaky, based on the output I recieved we had
processed the un-fullscreen but not the un-maximise.
It seems possible the wayland thread could process when there's only one
request in the queue.
Test Plan:
Couldn't reproduce the original issue, it's a blind patch but the
current tests still pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16955
Summary:
The primary reason for rewriting this effect was to clean up code and
fix spawning of multiple animations for a single window when user cycles
through virtual desktops very quickly.
Visually, the rewritten version doesn't deviate from the old version.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16454
If a full screen effect has been activated, we need to brighten main
windows because the full screen effect can dim windows on its own
(one such effect is the Present Windows, for example).
If the full screen effect is no longer active, we need to dim main
windows back.
Summary:
The ported effect looks quite similar to the C++ version except one
thing: it works correctly when user activates/deactivates a full
screen effect, for example the Desktop Cube effect.
Other than that, there are no behavioral or visual differences.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16452
Summary:
If a window is unminimized and the minimize animation is still active,
don't cancel the latter and start a new animation. Instead, try to
reverse already active animation and if that attempt failed, start a new
animation. This results in more smoother animations.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16451
Summary:
Effects that prefer to manipulate direction of animations sometimes need
to create animations in some particular state so later on they can be
played backward (swapping from and to is not enough and it would be wrong).
The proposed complete function lets such effects to fast-forward animations to
to the target position so they can be played backwards later on.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16450
Summary:
Consider current implementation of the Squash effect: if a window was
minimized, an animation will be started; if the window is unminimized
and the animation is still active (that can happen when user clicks on
app's icon really fast), the animation will be stopped and a new one will
be created. Such behavior can lead to rapid jumps in the observed
"animation".
A better approach would be first try to **reverse** the already active
animation, and if that attempt wasn't successful, start a new animation.
This patch introduces a new function to the scripted effects API that
lets JavaScript effects to control direction of animations. The
prototype of the function looks as follows:
redirect(<animation id(s)>, <direction>, [<termination policy>])
the first argument is an animation id or a list of animation ids, the
second argument specifies the new direction of the animation or
animations if a list of ids was passed as the first argument. The
third argument specifies whether the animation(s) should be terminated
when it(they) reaches the source position, currently it's relevant only
for animations that are created with set() function. The termination
policy argument is optional, by default it's Effect.TerminateAtSource.
We can use this function to fix issues with rapid jumps in the Squash
effect. Also, redirect() lets us to write effects for simple animations
in slightly different style: first, we have to start the main animation
(e.g. for the Dialog Parent effect, it would be dimming of main windows)
and then change direction of the animation depending on external events,
e.g. when the Desktop Cube effect is activated.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16449
Summary:
TimeLine has nice API for controlling its direction that can be re-used
later by AnimationEffect.
Test Plan: The existing tests for scripting effects still pass.
Reviewers: #kwin, davidedmundson, graesslin
Reviewed By: #kwin, davidedmundson, graesslin
Subscribers: davidedmundson, abetts, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16448
Summary:
The redirect modes control behavior of the timeline when its direction
is changed at the start or target position. For example, consider the
following piece of code:
TimeLine timeLine(1000ms, TimeLine::Forward);
timeLine.setDirection(TimeLine::Backward);
What should happen when the direction of the timeline was changed to go
backward? Should the current value of the timeline go from 1 to 0, or
should the timeline stop its "execution"?
In the relaxed mode, the timeline will go from 1 to 0.
In the strict mode, the timeline will stop its execution.
Different effects may prefer different modes for source and target
positions. For example, most C++ effect would prefer relaxed mode for
source position, and strict mode for target position. On the other side,
scripted effects(AnimationEffect) would prefer strict mode for source
position, and relaxed mode for target position(because of set).
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16447
Summary:
to successfully use kcrash when linking with as-needed (which is a default
flag on many linux distros) one also needs to call KCrash::initialize.
https://markmail.org/thread/zv5pheijaze72bzs
Test Plan: builds; correctly links kcrash
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16923
Summary:
When switching from maximised to full screen the geometry as kwin sees
it doesn't necessarily need to change, the test is wrong.
Also we can fix the XDGShell-deco tests.
wlshell-deco test still fails as before.
Test Plan: Tests pass \o/
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16922
Summary:
In shell surface, maximise mode and fullscreen are exclusive
fullscreen->toplevel should restore the state we had before maximising
Test Plan: testMaximisedToFullscreen unit test
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16921
Summary:
In the case of going from maximised to fullscreen when decorated the
geometry of the window (as far as kwin is concerned) could remain static
if we have no panels, but we still need a newly resized buffer from the
client.
When checking if we need a new buffer or to perform the geometry change
directly we need to compare the client size without borders.
Test Plan: maximizedToFullScreen unit test
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16920
Summary:
No one emits DecorationSettings::fontChanged signal, so if you change
the window title font, then titlebars might look differently after reboot.
Currently, there are two places where we can emit that signal:
- in KDecoration library itself;
- and in KWin.
Because we would need to listen for a Plasma specific D-Bus signal, the
latter option is preferable.
Surprisingly, KWin's implementation of DecorationSettingsPrivate already
reacts to refreshFonts D-Bus signal (even though indirectly), so all
what we have to do is get the current window title font in
SettingsImpl::readSettings, and if it's different from the previous one,
emit DecorationSettings::fontChanged signal.
BUG: 400980
FIXED-IN: 5.15.0
Test Plan:
* Increased the size of the window title font, titlebars got bigger;
* Decreased the font size, titlebars got smaller.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16908
Summary:
The layout from previous test leaked into this test if all tests are run
together. This change ensures that a proper layout for this test is set.
Test Plan: Test passes alone and when run together
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16903
Summary:
Fade, glide, and scale effect are mutually exclusive effects so they have
to be put into an exclusive group in the desktop effects kcm.
Test Plan: {F6418669}
Reviewers: #kwin, #plasma, #vdg, ngraham, graesslin
Reviewed By: #kwin, #plasma, #vdg, ngraham, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16858
Summary:
Currently, we have three effects that can be used to animate the
appearing of toplevel windows(fade, glide, scale) and one can enable
all three of them, which seems to be wrong. It doesn't make sense to have
glide and scale effect enabled, for example.
We couldn't put all three effects into an exclusive group before because
the fade effect animates not only toplevel windows but also popups. So,
if all three effects are in an exclusive group and you enable glide effect,
for example, then tooltips and other popups won't be faded in/out.
This patch splits the fade effect into two: the first effect (called Fade)
animates toplevel windows and the other one (called Fading Popups) animates
popup windows.
Test Plan:
Have been using the Fading Popups effect in combination with the Scale
effect for a couple of days. Haven't noticed any significant differences between
the new combination (Fading Popups + Scale) and the old combination
(Fade + Scale).
Reviewers: #kwin, #plasma, #vdg, graesslin
Reviewed By: #kwin, #plasma, graesslin
Subscribers: graesslin, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16836
Summary:
The test fails for unknown reasons on build.kde.org, but passes when
run on a development setup. As the code is going to be changed with
D15063 anyway, it is better to just disable the test for the time being.
Test Plan: Test gets skipped
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16895
Summary:
The current refresh rate is stored in OutputInterface. Move the getter
therefore in the AbstractOutput class.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16793
Summary: Removes unneeded includes and reorders the code in a sensible way.
Reviewers: #kwin
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16792
Summary:
Set the mode in AbstractOutput and call into the plugin
for final change on hardware.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T10016
Differential Revision: https://phabricator.kde.org/D16786
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:
Currently setDesktop and unsetDesktop were out of sync, with the latter
missing several important signals and updating of transients.
By using a a shared implementation we avoid that, it also allows for an
atomic move of a window between desktops.
setDesktop is changed back to be a moval of desktop as it currently
broke several unit tests as well as changing the behaviour of the move
to desktop shortcut on wayland.
Test Plan:
testBindings now passes
Moved windows with the context menu on X11
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16703
Summary:
If you resize a decorated client by using the resize user action(press
Alt + F3 > More Actions > Resize), then KWin will crash because it gets
stuck in an infinite loop (AbstractClient::performMoveResize <->
ShellClient::setGeometry).
Here's how KWin gets stuck in that loop:
* when you finish resizing the client, AbstractClient::keyPressEvent
will call AbstractClient::finishMoveResize;
* the first thing that finishMoveResize does is block geometry updates,
then it does some clean up (e.g. reset the value of isMoveResize(), etc),
updates the geometry of the client and when it's done, it will emit
clientFinishUserMoveResized signal;
* when PointerInputRedirection notices that signal, it will call
processDecorationMove on the client, which in its turn will indirectly
call AbstractClient::startMoveResize;
* when it's time to go back to AbstractClient::keyPressEvent, geometry
updates are unblocked and if there are any pending geometry updates,
then ShellClient::setGeometry will be called;
* ShellClient::setGeometry will eventually call ShellClient::doSetGeometry;
* ShellClient::doSetGeometry will call AbstractClient::performMoveResize
because AbstractClient::processDecorationMove indirectly called
AbstractClient::startMoveResize;
* AbstractClient::performMoveResize calls ShellClient::setGeometry;
* (at this point, KWin got stuck in the infinite loop)
This change swaps setMoveResizePointerButtonDown and finishMoveResize,
so processDecorationMove won't indirectly call startMoveResize.
BUG: 397577
FIXED-IN: 5.14.4
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16846
Summary:
If the cross fade animation is cancelled, we are not gracefully
unreference the previous window pixmap.
This change addresses that issue by using RAII approach to
reference/unreference the previous window pixmap.
Test Plan: Manually. The Maximize and the Morphing Popups effect still work.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16391
Summary:
With the plasma shell protocol, a ShellClient gets its role/window type
after it's created, so the cached value of the popupWindow property in
EffectWindow can be wrong.
In addition to that, the value of the popupWindow property still can be
wrong because plasma shell surfaces don't have xdg-popup role, so we need
to check NetWM-based window type in ShellClient::isPopupWindow.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16835
Summary:
Kwin tried to not use kcrash by not linking against it.
KIO now links against KCrash as we link against KIO we indirectly link
against KCrash and thus now link and launch kcrash on wayland. This
breaks coredump.
Arguably it should be fixed in KIO, but it's non-trivial.
The advantage of this approach is it allows us to enable drkonqi for
nested mode in the future, or make a non-gui drkonqi that just saves
logs.
Test Plan: Compiles
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: zzag, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16834
