kwin/effects/slidingpopups/slidingpopups.h

119 lines
3.2 KiB
C
Raw Normal View History

/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2009 Marco Martin notmart@gmail.com
2019-09-29 14:03:25 +00:00
Copyright (C) 2018 Vlad Zahorodnii <vladzzag@gmail.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_SLIDINGPOPUPS_H
#define KWIN_SLIDINGPOPUPS_H
// Include with base class for effects.
#include <kwineffects.h>
namespace KWin
{
class SlidingPopupsEffect : public Effect
2011-01-30 14:34:42 +00:00
{
Q_OBJECT
Q_PROPERTY(int slideInDuration READ slideInDuration)
Q_PROPERTY(int slideOutDuration READ slideOutDuration)
2011-01-30 14:34:42 +00:00
public:
SlidingPopupsEffect();
~SlidingPopupsEffect() override;
void prePaintWindow(EffectWindow *w, WindowPrePaintData &data, int time) override;
void paintWindow(EffectWindow *w, int mask, QRegion region, WindowPaintData &data) override;
void postPaintWindow(EffectWindow *w) override;
void reconfigure(ReconfigureFlags flags) override;
bool isActive() const override;
int requestedEffectChainPosition() const override {
return 40;
}
static bool supported();
int slideInDuration() const;
int slideOutDuration() const;
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 eventFilter(QObject *watched, QEvent *event) override;
private Q_SLOTS:
void slotWindowAdded(EffectWindow *w);
void slotWindowDeleted(EffectWindow *w);
void slotPropertyNotify(EffectWindow *w, long atom);
void slotWaylandSlideOnShowChanged(EffectWindow *w);
void slideIn(EffectWindow *w);
void slideOut(EffectWindow *w);
[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 stopAnimations();
2011-01-30 14:34:42 +00:00
private:
void setupAnimData(EffectWindow *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 setupInternalWindowSlide(EffectWindow *w);
long m_atom;
int m_slideLength;
std::chrono::milliseconds m_slideInDuration;
std::chrono::milliseconds m_slideOutDuration;
enum class AnimationKind {
In,
Out
};
struct Animation {
AnimationKind kind;
TimeLine timeLine;
};
[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
QHash<EffectWindow *, Animation> m_animations;
enum class Location {
Left,
Top,
Right,
Bottom
};
struct AnimationData {
int offset;
Location location;
std::chrono::milliseconds slideInDuration;
std::chrono::milliseconds slideOutDuration;
int slideLength;
};
QHash<const EffectWindow*, AnimationData> m_animationsData;
2011-01-30 14:34:42 +00:00
};
inline int SlidingPopupsEffect::slideInDuration() const
{
return m_slideInDuration.count();
}
inline int SlidingPopupsEffect::slideOutDuration() const
{
return m_slideOutDuration.count();
}
} // namespace
#endif