kwin/effects/slidingpopups/slidingpopups.cpp

540 lines
17 KiB
C++
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2009 Marco Martin notmart @gmail.com
SPDX-FileCopyrightText: 2018 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "slidingpopups.h"
#include "slidingpopupsconfig.h"
2014-02-10 16:59:16 +00:00
#include <QApplication>
#include <QFontMetrics>
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
#include <QWindow>
#include <KWaylandServer/surface_interface.h>
#include <KWaylandServer/slide_interface.h>
#include <KWaylandServer/display.h>
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
#include <KWindowEffects>
Q_DECLARE_METATYPE(KWindowEffects::SlideFromLocation)
namespace KWin
{
SlidingPopupsEffect::SlidingPopupsEffect()
2011-01-30 14:34:42 +00:00
{
initConfig<SlidingPopupsConfig>();
KWaylandServer::Display *display = effects->waylandDisplay();
if (display) {
new KWaylandServer::SlideManagerInterface(display, this);
}
m_slideLength = QFontMetrics(qApp->font()).height() * 8;
2014-02-10 16:59:16 +00:00
m_atom = effects->announceSupportProperty("_KDE_SLIDE", this);
connect(effects, &EffectsHandler::windowAdded, this, &SlidingPopupsEffect::slotWindowAdded);
connect(effects, &EffectsHandler::windowClosed, this, &SlidingPopupsEffect::slideOut);
connect(effects, &EffectsHandler::windowDeleted, this, &SlidingPopupsEffect::slotWindowDeleted);
connect(effects, &EffectsHandler::propertyNotify, this, &SlidingPopupsEffect::slotPropertyNotify);
connect(effects, &EffectsHandler::windowShown, this, &SlidingPopupsEffect::slideIn);
connect(effects, &EffectsHandler::windowHidden, this, &SlidingPopupsEffect::slideOut);
connect(effects, &EffectsHandler::xcbConnectionChanged, this,
[this] {
m_atom = effects->announceSupportProperty(QByteArrayLiteral("_KDE_SLIDE"), this);
}
);
[effects/slidingpopups] Don't crash when sliding virtual desktops 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
2018-11-05 12:59:42 +00:00
connect(effects, qOverload<int, int, EffectWindow *>(&EffectsHandler::desktopChanged),
this, &SlidingPopupsEffect::stopAnimations);
connect(effects, &EffectsHandler::activeFullScreenEffectChanged,
this, &SlidingPopupsEffect::stopAnimations);
reconfigure(ReconfigureAll);
2011-01-30 14:34:42 +00:00
}
SlidingPopupsEffect::~SlidingPopupsEffect()
2011-01-30 14:34:42 +00:00
{
}
bool SlidingPopupsEffect::supported()
{
return effects->animationsSupported();
}
void SlidingPopupsEffect::reconfigure(ReconfigureFlags flags)
{
Q_UNUSED(flags)
SlidingPopupsConfig::self()->read();
m_slideInDuration = std::chrono::milliseconds(
static_cast<int>(animationTime(SlidingPopupsConfig::slideInTime() != 0 ? SlidingPopupsConfig::slideInTime() : 150)));
m_slideOutDuration = std::chrono::milliseconds(
static_cast<int>(animationTime(SlidingPopupsConfig::slideOutTime() != 0 ? SlidingPopupsConfig::slideOutTime() : 250)));
auto animationIt = m_animations.begin();
while (animationIt != m_animations.end()) {
const auto duration = ((*animationIt).kind == AnimationKind::In)
? m_slideInDuration
: m_slideOutDuration;
(*animationIt).timeLine.setDuration(duration);
++animationIt;
}
auto dataIt = m_animationsData.begin();
while (dataIt != m_animationsData.end()) {
(*dataIt).slideInDuration = m_slideInDuration;
(*dataIt).slideOutDuration = m_slideOutDuration;
++dataIt;
}
}
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
void SlidingPopupsEffect::prePaintWindow(EffectWindow *w, WindowPrePaintData &data, std::chrono::milliseconds presentTime)
2011-01-30 14:34:42 +00:00
{
auto animationIt = m_animations.find(w);
if (animationIt == m_animations.end()) {
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
effects->prePaintWindow(w, data, presentTime);
return;
}
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
std::chrono::milliseconds delta = std::chrono::milliseconds::zero();
if (animationIt->lastPresentTime.count()) {
delta = presentTime - animationIt->lastPresentTime;
}
animationIt->lastPresentTime = presentTime;
(*animationIt).timeLine.update(delta);
data.setTransformed();
w->enablePainting(EffectWindow::PAINT_DISABLED | EffectWindow::PAINT_DISABLED_BY_DELETE);
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
effects->prePaintWindow(w, data, presentTime);
2011-01-30 14:34:42 +00:00
}
void SlidingPopupsEffect::paintWindow(EffectWindow *w, int mask, QRegion region, WindowPaintData &data)
2011-01-30 14:34:42 +00:00
{
auto animationIt = m_animations.constFind(w);
if (animationIt == m_animations.constEnd()) {
effects->paintWindow(w, mask, region, data);
return;
2011-01-30 14:34:42 +00:00
}
const AnimationData &animData = m_animationsData[w];
const int slideLength = (animData.slideLength > 0) ? animData.slideLength : m_slideLength;
const QRect screenRect = effects->clientArea(FullScreenArea, w->screen(), effects->currentDesktop());
int splitPoint = 0;
const QRect geo = w->expandedGeometry();
const qreal t = (*animationIt).timeLine.value();
switch (animData.location) {
case Location::Left:
if (slideLength < geo.width()) {
data.multiplyOpacity(t);
}
data.translate(-interpolate(qMin(geo.width(), slideLength), 0.0, t));
splitPoint = geo.width() - (geo.x() + geo.width() - screenRect.x() - animData.offset);
region &= QRegion(geo.x() + splitPoint, geo.y(), geo.width() - splitPoint, geo.height());
break;
case Location::Top:
if (slideLength < geo.height()) {
data.multiplyOpacity(t);
}
data.translate(0.0, -interpolate(qMin(geo.height(), slideLength), 0.0, t));
splitPoint = geo.height() - (geo.y() + geo.height() - screenRect.y() - animData.offset);
region &= QRegion(geo.x(), geo.y() + splitPoint, geo.width(), geo.height() - splitPoint);
break;
case Location::Right:
if (slideLength < geo.width()) {
data.multiplyOpacity(t);
}
data.translate(interpolate(qMin(geo.width(), slideLength), 0.0, t));
splitPoint = screenRect.x() + screenRect.width() - geo.x() - animData.offset;
region &= QRegion(geo.x(), geo.y(), splitPoint, geo.height());
break;
case Location::Bottom:
default:
if (slideLength < geo.height()) {
data.multiplyOpacity(t);
}
data.translate(0.0, interpolate(qMin(geo.height(), slideLength), 0.0, t));
splitPoint = screenRect.y() + screenRect.height() - geo.y() - animData.offset;
region &= QRegion(geo.x(), geo.y(), geo.width(), splitPoint);
}
effects->paintWindow(w, mask, region, data);
2011-01-30 14:34:42 +00:00
}
void SlidingPopupsEffect::postPaintWindow(EffectWindow *w)
2011-01-30 14:34:42 +00:00
{
auto animationIt = m_animations.find(w);
if (animationIt != m_animations.end()) {
if ((*animationIt).timeLine.done()) {
if (w->isDeleted()) {
w->unrefWindow();
} else {
w->setData(WindowForceBackgroundContrastRole, QVariant());
w->setData(WindowForceBlurRole, QVariant());
}
m_animations.erase(animationIt);
}
w->addRepaintFull();
}
2011-01-30 14:34:42 +00:00
effects->postPaintWindow(w);
}
void SlidingPopupsEffect::slotWindowAdded(EffectWindow *w)
2011-01-30 14:34:42 +00:00
{
//X11
if (m_atom != XCB_ATOM_NONE) {
slotPropertyNotify(w, m_atom);
}
//Wayland
if (auto surf = w->surface()) {
slotWaylandSlideOnShowChanged(w);
connect(surf, &KWaylandServer::SurfaceInterface::slideOnShowHideChanged, this, [this, surf] {
slotWaylandSlideOnShowChanged(effects->findWindow(surf));
});
}
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
if (auto internal = w->internalWindow()) {
internal->installEventFilter(this);
setupInternalWindowSlide(w);
}
slideIn(w);
2011-01-30 14:34:42 +00:00
}
void SlidingPopupsEffect::slotWindowDeleted(EffectWindow *w)
2011-01-30 14:34:42 +00:00
{
m_animations.remove(w);
m_animationsData.remove(w);
2011-01-30 14:34:42 +00:00
}
void SlidingPopupsEffect::slotPropertyNotify(EffectWindow *w, long atom)
2011-01-30 14:34:42 +00:00
{
if (!w || atom != m_atom || m_atom == XCB_ATOM_NONE) {
return;
}
// _KDE_SLIDE atom format(each field is an uint32_t):
// <offset> <location> [<slide in duration>] [<slide out duration>] [<slide length>]
//
// If offset is equal to -1, this effect will decide what offset to use
// given edge of the screen, from which the window has to slide.
//
// If slide in duration is equal to 0 milliseconds, the default slide in
// duration will be used. Same with the slide out duration.
//
// NOTE: If only slide in duration has been provided, then it will be
// also used as slide out duration. I.e. if you provided only slide in
// duration, then slide in duration == slide out duration.
const QByteArray rawAtomData = w->readProperty(m_atom, m_atom, 32);
if (rawAtomData.isEmpty()) {
// Property was removed, thus also remove the effect for window
if (w->data(WindowClosedGrabRole).value<void *>() == this) {
w->setData(WindowClosedGrabRole, QVariant());
}
m_animations.remove(w);
m_animationsData.remove(w);
return;
2011-01-30 14:34:42 +00:00
}
// Offset and location are required.
if (static_cast<size_t>(rawAtomData.size()) < sizeof(uint32_t) * 2) {
return;
}
const auto *atomData = reinterpret_cast<const uint32_t *>(rawAtomData.data());
AnimationData &animData = m_animationsData[w];
animData.offset = atomData[0];
switch (atomData[1]) {
case 0: // West
animData.location = Location::Left;
break;
case 1: // North
animData.location = Location::Top;
break;
case 2: // East
animData.location = Location::Right;
break;
case 3: // South
default:
animData.location = Location::Bottom;
break;
}
if (static_cast<size_t>(rawAtomData.size()) >= sizeof(uint32_t) * 3) {
animData.slideInDuration = std::chrono::milliseconds(atomData[2]);
if (static_cast<size_t>(rawAtomData.size()) >= sizeof(uint32_t) * 4) {
animData.slideOutDuration = std::chrono::milliseconds(atomData[3]);
} else {
animData.slideOutDuration = animData.slideInDuration;
}
2011-01-30 14:34:42 +00:00
} else {
animData.slideInDuration = m_slideInDuration;
animData.slideOutDuration = m_slideOutDuration;
}
if (static_cast<size_t>(rawAtomData.size()) >= sizeof(uint32_t) * 5) {
animData.slideLength = atomData[4];
} else {
animData.slideLength = 0;
}
setupAnimData(w);
}
void SlidingPopupsEffect::setupAnimData(EffectWindow *w)
{
const QRect screenRect = effects->clientArea(FullScreenArea, w->screen(), effects->currentDesktop());
const QRect windowGeo = w->geometry();
AnimationData &animData = m_animationsData[w];
if (animData.offset == -1) {
switch (animData.location) {
case Location::Left:
animData.offset = qMax(windowGeo.left() - screenRect.left(), 0);
break;
case Location::Top:
animData.offset = qMax(windowGeo.top() - screenRect.top(), 0);
break;
case Location::Right:
animData.offset = qMax(screenRect.right() - windowGeo.right(), 0);
break;
case Location::Bottom:
default:
animData.offset = qMax(screenRect.bottom() - windowGeo.bottom(), 0);
break;
}
}
// sanitize
switch (animData.location) {
case Location::Left:
animData.offset = qMax(windowGeo.left() - screenRect.left(), animData.offset);
break;
case Location::Top:
animData.offset = qMax(windowGeo.top() - screenRect.top(), animData.offset);
break;
case Location::Right:
animData.offset = qMax(screenRect.right() - windowGeo.right(), animData.offset);
break;
case Location::Bottom:
default:
animData.offset = qMax(screenRect.bottom() - windowGeo.bottom(), animData.offset);
break;
}
animData.slideInDuration = (animData.slideInDuration.count() != 0)
? animData.slideInDuration
: m_slideInDuration;
animData.slideOutDuration = (animData.slideOutDuration.count() != 0)
? animData.slideOutDuration
: m_slideOutDuration;
// Grab the window, so other windowClosed effects will ignore it
w->setData(WindowClosedGrabRole, QVariant::fromValue(static_cast<void*>(this)));
2011-01-30 14:34:42 +00:00
}
void SlidingPopupsEffect::slotWaylandSlideOnShowChanged(EffectWindow* w)
{
if (!w) {
return;
}
KWaylandServer::SurfaceInterface *surf = w->surface();
if (!surf) {
return;
}
if (surf->slideOnShowHide()) {
AnimationData &animData = m_animationsData[w];
animData.offset = surf->slideOnShowHide()->offset();
switch (surf->slideOnShowHide()->location()) {
case KWaylandServer::SlideInterface::Location::Top:
animData.location = Location::Top;
break;
case KWaylandServer::SlideInterface::Location::Left:
animData.location = Location::Left;
break;
case KWaylandServer::SlideInterface::Location::Right:
animData.location = Location::Right;
break;
case KWaylandServer::SlideInterface::Location::Bottom:
default:
animData.location = Location::Bottom;
break;
}
animData.slideLength = 0;
animData.slideInDuration = m_slideInDuration;
animData.slideOutDuration = m_slideOutDuration;
setupAnimData(w);
}
}
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
void SlidingPopupsEffect::setupInternalWindowSlide(EffectWindow *w)
{
if (!w) {
return;
}
auto internal = w->internalWindow();
if (!internal) {
return;
}
const QVariant slideProperty = internal->property("kwin_slide");
if (!slideProperty.isValid()) {
return;
}
Location location;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
switch (slideProperty.value<KWindowEffects::SlideFromLocation>()) {
case KWindowEffects::BottomEdge:
location = Location::Bottom;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
break;
case KWindowEffects::TopEdge:
location = Location::Top;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
break;
case KWindowEffects::RightEdge:
location = Location::Right;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
break;
case KWindowEffects::LeftEdge:
location = Location::Left;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
break;
default:
return;
}
AnimationData &animData = m_animationsData[w];
animData.location = location;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
bool intOk = false;
animData.offset = internal->property("kwin_slide_offset").toInt(&intOk);
if (!intOk) {
animData.offset = -1;
}
animData.slideLength = 0;
animData.slideInDuration = m_slideInDuration;
animData.slideOutDuration = m_slideOutDuration;
setupAnimData(w);
}
bool SlidingPopupsEffect::eventFilter(QObject *watched, QEvent *event)
{
auto internal = qobject_cast<QWindow*>(watched);
if (internal && event->type() == QEvent::DynamicPropertyChange) {
QDynamicPropertyChangeEvent *pe = static_cast<QDynamicPropertyChangeEvent*>(event);
if (pe->propertyName() == "kwin_slide" || pe->propertyName() == "kwin_slide_offset") {
if (auto w = effects->findWindow(internal)) {
setupInternalWindowSlide(w);
}
}
}
return false;
}
void SlidingPopupsEffect::slideIn(EffectWindow *w)
{
if (effects->activeFullScreenEffect()) {
return;
}
if (!w->isVisible()) {
return;
}
auto dataIt = m_animationsData.constFind(w);
if (dataIt == m_animationsData.constEnd()) {
return;
}
Animation &animation = m_animations[w];
animation.kind = AnimationKind::In;
animation.timeLine.setDirection(TimeLine::Forward);
animation.timeLine.setDuration((*dataIt).slideInDuration);
animation.timeLine.setEasingCurve(QEasingCurve::OutCubic);
// If the opposite animation (Out) was active and it had shorter duration,
// at this point, the timeline can end up in the "done" state. Thus, we have
// to reset it.
if (animation.timeLine.done()) {
animation.timeLine.reset();
}
w->setData(WindowAddedGrabRole, QVariant::fromValue(static_cast<void*>(this)));
w->setData(WindowForceBackgroundContrastRole, QVariant(true));
w->setData(WindowForceBlurRole, QVariant(true));
w->addRepaintFull();
}
void SlidingPopupsEffect::slideOut(EffectWindow *w)
{
if (effects->activeFullScreenEffect()) {
return;
}
if (!w->isVisible()) {
return;
}
auto dataIt = m_animationsData.constFind(w);
if (dataIt == m_animationsData.constEnd()) {
return;
}
if (w->isDeleted()) {
w->refWindow();
}
Animation &animation = m_animations[w];
animation.kind = AnimationKind::Out;
animation.timeLine.setDirection(TimeLine::Backward);
animation.timeLine.setDuration((*dataIt).slideOutDuration);
// this is effectively InCubic because the direction is reversed
animation.timeLine.setEasingCurve(QEasingCurve::OutCubic);
// If the opposite animation (In) was active and it had shorter duration,
// at this point, the timeline can end up in the "done" state. Thus, we have
// to reset it.
if (animation.timeLine.done()) {
animation.timeLine.reset();
}
w->setData(WindowClosedGrabRole, QVariant::fromValue(static_cast<void*>(this)));
w->setData(WindowForceBackgroundContrastRole, QVariant(true));
w->setData(WindowForceBlurRole, QVariant(true));
w->addRepaintFull();
}
[effects/slidingpopups] Don't crash when sliding virtual desktops 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
2018-11-05 12:59:42 +00:00
void SlidingPopupsEffect::stopAnimations()
{
for (auto it = m_animations.constBegin(); it != m_animations.constEnd(); ++it) {
EffectWindow *w = it.key();
if (w->isDeleted()) {
w->unrefWindow();
} else {
w->setData(WindowForceBackgroundContrastRole, QVariant());
w->setData(WindowForceBlurRole, QVariant());
}
}
m_animations.clear();
}
bool SlidingPopupsEffect::isActive() const
{
return !m_animations.isEmpty();
}
} // namespace