2020-08-02 22:22:19 +00:00
|
|
|
/*
|
|
|
|
KWin - the KDE window manager
|
|
|
|
This file is part of the KDE project.
|
2010-05-11 18:45:39 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-FileCopyrightText: 2007 Philip Falkner <philip.falkner@gmail.com>
|
|
|
|
SPDX-FileCopyrightText: 2009 Martin Gräßlin <mgraesslin@kde.org>
|
|
|
|
SPDX-FileCopyrightText: 2010 Alexandre Pereira <pereira.alex@gmail.com>
|
|
|
|
SPDX-FileCopyrightText: 2018 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
2010-05-11 18:45:39 +00:00
|
|
|
|
2020-08-02 22:22:19 +00:00
|
|
|
SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*/
|
2010-05-11 18:45:39 +00:00
|
|
|
|
|
|
|
#ifndef KWIN_GLIDE_H
|
|
|
|
#define KWIN_GLIDE_H
|
|
|
|
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
// kwineffects
|
2010-05-11 18:45:39 +00:00
|
|
|
#include <kwineffects.h>
|
|
|
|
|
|
|
|
namespace KWin
|
|
|
|
{
|
|
|
|
|
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
|
|
|
struct GlideAnimation
|
|
|
|
{
|
|
|
|
TimeLine timeLine;
|
|
|
|
std::chrono::milliseconds lastPresentTime = std::chrono::milliseconds::zero();
|
|
|
|
};
|
|
|
|
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
class GlideEffect : public Effect
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
2011-02-25 21:06:02 +00:00
|
|
|
Q_OBJECT
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
Q_PROPERTY(int duration READ duration)
|
|
|
|
Q_PROPERTY(RotationEdge inRotationEdge READ inRotationEdge)
|
|
|
|
Q_PROPERTY(qreal inRotationAngle READ inRotationAngle)
|
|
|
|
Q_PROPERTY(qreal inDistance READ inDistance)
|
|
|
|
Q_PROPERTY(qreal inOpacity READ inOpacity)
|
|
|
|
Q_PROPERTY(RotationEdge outRotationEdge READ outRotationEdge)
|
|
|
|
Q_PROPERTY(qreal outRotationAngle READ outRotationAngle)
|
|
|
|
Q_PROPERTY(qreal outDistance READ outDistance)
|
|
|
|
Q_PROPERTY(qreal outOpacity READ outOpacity)
|
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
public:
|
|
|
|
GlideEffect();
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
~GlideEffect() override;
|
|
|
|
|
|
|
|
void reconfigure(ReconfigureFlags flags) override;
|
|
|
|
|
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 prePaintScreen(ScreenPrePaintData &data, std::chrono::milliseconds presentTime) override;
|
|
|
|
void prePaintWindow(EffectWindow *w, WindowPrePaintData &data, std::chrono::milliseconds presentTime) override;
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
void paintWindow(EffectWindow *w, int mask, QRegion region, WindowPaintData &data) override;
|
|
|
|
void postPaintScreen() override;
|
|
|
|
|
|
|
|
bool isActive() const override;
|
|
|
|
int requestedEffectChainPosition() const override;
|
2014-03-24 10:50:09 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
static bool supported();
|
2012-08-11 09:24:37 +00:00
|
|
|
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
enum RotationEdge {
|
|
|
|
Top = 0,
|
|
|
|
Right = 1,
|
|
|
|
Bottom = 2,
|
|
|
|
Left = 3
|
|
|
|
};
|
|
|
|
Q_ENUM(RotationEdge)
|
|
|
|
|
|
|
|
int duration() const;
|
|
|
|
RotationEdge inRotationEdge() const;
|
|
|
|
qreal inRotationAngle() const;
|
|
|
|
qreal inDistance() const;
|
|
|
|
qreal inOpacity() const;
|
|
|
|
RotationEdge outRotationEdge() const;
|
|
|
|
qreal outRotationAngle() const;
|
|
|
|
qreal outDistance() const;
|
|
|
|
qreal outOpacity() const;
|
|
|
|
|
|
|
|
private Q_SLOTS:
|
|
|
|
void windowAdded(EffectWindow *w);
|
|
|
|
void windowClosed(EffectWindow *w);
|
|
|
|
void windowDeleted(EffectWindow *w);
|
|
|
|
void windowDataChanged(EffectWindow *w, int role);
|
2011-02-25 21:06:02 +00:00
|
|
|
|
2011-01-30 14:34:42 +00:00
|
|
|
private:
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
bool isGlideWindow(EffectWindow *w) const;
|
|
|
|
|
|
|
|
std::chrono::milliseconds m_duration;
|
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
|
|
|
QHash<EffectWindow *, GlideAnimation> m_animations;
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
|
|
|
|
struct GlideParams {
|
|
|
|
RotationEdge edge;
|
|
|
|
struct {
|
|
|
|
qreal from;
|
|
|
|
qreal to;
|
|
|
|
} angle, distance, opacity;
|
2010-05-11 18:45:39 +00:00
|
|
|
};
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
|
|
|
|
GlideParams m_inParams;
|
|
|
|
GlideParams m_outParams;
|
2011-01-30 14:34:42 +00:00
|
|
|
};
|
2010-05-11 18:45:39 +00:00
|
|
|
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
inline int GlideEffect::requestedEffectChainPosition() const
|
2011-01-30 14:34:42 +00:00
|
|
|
{
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
return 50;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline int GlideEffect::duration() const
|
|
|
|
{
|
|
|
|
return m_duration.count();
|
|
|
|
}
|
|
|
|
|
|
|
|
inline GlideEffect::RotationEdge GlideEffect::inRotationEdge() const
|
|
|
|
{
|
|
|
|
return m_inParams.edge;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::inRotationAngle() const
|
|
|
|
{
|
|
|
|
return m_inParams.angle.from;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::inDistance() const
|
|
|
|
{
|
|
|
|
return m_inParams.distance.from;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::inOpacity() const
|
|
|
|
{
|
|
|
|
return m_inParams.opacity.from;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline GlideEffect::RotationEdge GlideEffect::outRotationEdge() const
|
|
|
|
{
|
|
|
|
return m_outParams.edge;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::outRotationAngle() const
|
|
|
|
{
|
|
|
|
return m_outParams.angle.to;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::outDistance() const
|
|
|
|
{
|
|
|
|
return m_outParams.distance.to;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline qreal GlideEffect::outOpacity() const
|
|
|
|
{
|
|
|
|
return m_outParams.opacity.to;
|
|
|
|
}
|
2010-05-11 18:45:39 +00:00
|
|
|
|
[effects] Rewrite the Glide effect
Summary:
There are several reasons why I "re-wrote" the Glide effect:
* it doesn't work correctly because it suffers from undesired perspective distortions: {F5914378}
The worst part is that windows are distorted so much on multiple monitor setups that it's hard to say whether that's glide animation.
* window close animation is not quite intuitive: if the close button is
located at the top and I click it, I would expect that window is
rotated around the bottom edge, not the top; (IMHO)
* it's too much distracting when working on something for quite good
amount of time: e.g. when editing photos, which involves a big number
of different dialogs;
* there are issues with deletion of QTimeLine;
* windows are not gracefully released if some other effect grabs them;
* its code doesn't follow common coding style in KWin.
So, the "new" Glide effect is more subtle, it's possible to have
different rotation edges for window open/close animations, it doesn't
animate special windows(like audio volume feedback), the code is simpler
and readable. Yet, there are some issues with QTimeLine, which are
common to all effects in KWin anyway.
### Demos
{F5889803}
//Window Open Animation//
{F5889804}
//Window Close Animation//
{F5889805, layout=center, size=full}
//KCM//
CCBUG: 394245
Test Plan:
* Enabled the Glide effect
* Closed System Settings
* Opened it again
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13338
2018-06-01 09:56:33 +00:00
|
|
|
} // namespace KWin
|
2010-05-11 18:45:39 +00:00
|
|
|
|
|
|
|
#endif
|