For what reason ever motion manager thinks that windows are not
moving during the start animation (but are during the stop animation).
So we also have to look on the timeline to decide whether we should
disable lanczos filter on the windows.
Now wonder the animation was stuttering.
BUG: 274292
FIXED-IN: 4.7.0
The KWin::TimeLine class was only a small wrapper around QTimeLine
without adding anything to QTimeLine what is not present in QTimeLine.
The initial idea was to make it possible to provide more curve shapes.
This is now obsoleted by Qt shipping more useful curves with QTimeLine.
So let's clean up a little bit and use QTimeLine directly instead of
the small wrapper.
All effects are adjusted to use QTimeLine directly.
Client and Unmanaged use a signal to notify that they are about to be closed.
The EffectsHandlerImpl is connected to those signals and emits the appropriate
windowClosed signal to which the effects are connected.
All previously existing windowAdded methods are renamed to slotWindowAdded.
EffectsHandlerImpl is connected to Workspace's clientAdded signal, which is
emitted a little bit earlier than the previous direct method call. This might
change behavior.
Another signal is added to Workspace to signal that an unmanaged is added.
Since the EffectFrames have been moved into KWin core nothing in the
Effects lib actually used Plasma. The only remaining method is moved
to core as it's not used in the Effects. The Effects itself still
link against Plasma, so nothing changes for them.
The Plasma includes in the kwineffects header seemed to pull in
quite some additional headers, so the includes in some effects have
to be adjusted (most often KConfigGroup). This should speed up the
compilation of the library and the effects.
into KWin's global namespace. Morever None already kind of clashes with X's None.
CCMAIL: kde@martin-graesslin.com
svn path=/trunk/KDE/kdebase/workspace/; revision=1170588
Allows to move a window with a fixed position to another desktop. This is only
available in present windows mode as in normal mode each mouse movement results
in a window movement and therefore not possible.
CCBUG: 249337
svn path=/trunk/KDE/kdebase/workspace/; revision=1169324
This works around crashers if a key is pressed directly after activating the effect.
Working around is not the perfect solution, but we already block mouse events, so it
is consistent. And unfortunately the effect has become difficult to maintain and I
fear it's like chasing one crash after the other if we allow user interaction during
the animations.
CCBUG: 244813
svn path=/trunk/KDE/kdebase/workspace/; revision=1169048
Pager reported two rows, which does not make sense and caused the grid to be in
an inconsistent state.
CCBUG: 248817
svn path=/trunk/KDE/kdebase/workspace/; revision=1169041
Rendering of the EffectFrame is moved into the scene as Scene::EffectFrame with a concrete implementation in SceneXrender and SceneOpenGL.
A factory method for an EffectFrame is added to the EffectsHandler, which is used by the effects.
Next step: pass the EffectFrame through all effects, so that effects can transform, blur, invert whatever it.
svn path=/trunk/KDE/kdebase/workspace/; revision=1151271
Used in cube animation for all sticky windows and in desktop grid for the add/remove desktops window.
svn path=/trunk/KDE/kdebase/workspace/; revision=1137489
That is remove the window from all desktops on drag begin and attach the window to the mouse cursor. On release add them back to all desktop.
That way it's possible to move pinned windows to other screens and it fixes a crash.
BUG: 220582
svn path=/trunk/KDE/kdebase/workspace/; revision=1068482
That case needs some more improvement as it zooms to the black area and suddenly replaces the screen with the actual windows.
BUG: 219721
svn path=/trunk/KDE/kdebase/workspace/; revision=1065215
* on drag start rearrange windows in old desktop
* while moving having window attached to mouse cursor
* on drop rearrange windows in new desktop
svn path=/trunk/KDE/kdebase/workspace/; revision=1049583
Martin Gräßlin