Re: panels and popups sliding effect
Am Sonntag 26 Juli 2009 12:55:55 schrieb Marco Martin: On Saturday 25 July 2009, Aaron J. Seigo wrote: On Friday 24 July 2009, Marco Martin wrote: what about a small library (just statics probably) in workspace to deal with this stuff? KWindowSystemExtra? the code needs to be accessible from libplasma though so that e.g. PopupApplet can animate its stuff. that's why i suggested Animator. a Plasma::WindowEffects namespace would be fine as well imo. i'm really on the fence on where to put this and how to call it. Becasue if we put other stuff like that like the taskbar thumbnails and the glow effect they wouldn't have much to do with animation, and i'm kinda wondering if plasma is the right namespace/lib for that, hmm.. anyways next patch is a tiny WindowEffect namespace (or maybe WindowUtils? so it mnatches with PaintUtils) what about having a small lib in workspace/lib? Could be difficult for the thumbnails as IIRC they are set in libplasma, but that is probably solveable as well. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Sunday 26 July 2009, Martin Gräßlin wrote: Am Sonntag 26 Juli 2009 12:55:55 schrieb Marco Martin: On Saturday 25 July 2009, Aaron J. Seigo wrote: On Friday 24 July 2009, Marco Martin wrote: what about a small library (just statics probably) in workspace to deal with this stuff? KWindowSystemExtra? the code needs to be accessible from libplasma though so that e.g. PopupApplet can animate its stuff. that's why i suggested Animator. a Plasma::WindowEffects namespace would be fine as well imo. i'm really on the fence on where to put this and how to call it. Becasue if we put other stuff like that like the taskbar thumbnails and the glow effect they wouldn't have much to do with animation, and i'm kinda wondering if plasma is the right namespace/lib for that, hmm.. anyways next patch is a tiny WindowEffect namespace (or maybe WindowUtils? so it mnatches with PaintUtils) what about having a small lib in workspace/lib? Could be difficult for the thumbnails as IIRC they are set in libplasma, but that is probably solveable as well. problem with workspace is that we need it in libplasma, for Dialog::animateShow Dialog::animateHide -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Sunday 26 July 2009, Marco Martin wrote:
On Saturday 25 July 2009, Aaron J. Seigo wrote:
On Friday 24 July 2009, Marco Martin wrote:
what about a small library (just statics probably) in workspace to deal
with this stuff? KWindowSystemExtra?
the code needs to be accessible from libplasma though so that e.g.
PopupApplet can animate its stuff.
that's why i suggested Animator. a Plasma::WindowEffects namespace
would
be fine as well imo.
i'm really on the fence on where to put this and how to call it.
Becasue if we put other stuff like that like the taskbar thumbnails and the
glow effect they wouldn't have much to do with animation, and i'm kinda
wondering if plasma is the right namespace/lib for that, hmm..
anyways next patch is a tiny WindowEffect namespace (or maybe
WindowUtils?
so it mnatches with PaintUtils)
here it is
Cheers,
Marco Martin
Index: dialog.h
===
--- dialog.h (revision 1002551)
+++ dialog.h (working copy)
@@ -120,6 +120,7 @@
bool eventFilter(QObject *watched, QEvent *event);
void hideEvent(QHideEvent *event);
void showEvent(QShowEvent *event);
+void focusInEvent(QFocusEvent *event);
void mouseMoveEvent(QMouseEvent *event);
void mousePressEvent(QMouseEvent *event);
void mouseReleaseEvent(QMouseEvent *event);
Index: windoweffects.cpp
===
--- windoweffects.cpp (revision 0)
+++ windoweffects.cpp (revision 0)
@@ -0,0 +1,83 @@
+/*
+ * Copyright 2009 Marco Martin notm...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Library General Public License as
+ * published by the Free Software Foundation; either version 2, 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 Library General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include windoweffects.h
+
+#include QVarLengthArray
+
+
+namespace Plasma
+{
+
+namespace WindowEffects
+{
+
+void setSlidingWindow(WId id, Plasma::Location location)
+{
+#ifdef Q_WS_X11
+Display *dpy = QX11Info::display();
+//set again the atom, the location could have changed
+QDesktopWidget *desktop = QApplication::desktop();
+
+Window dummy;
+int x;
+int y;
+uint width;
+uint height;
+uint bw;
+uint d;
+XGetGeometry(dpy, id, dummy, x, y, width, height, bw, d);
+
+QRect avail = desktop-availableGeometry(QPoint(x, y));//desktop-screenNumber(pos()));
+
+Atom atom = XInternAtom( dpy, _KDE_SLIDE, False );
+QVarLengthArraylong, 1024 data(2);
+
+switch (location) {
+case LeftEdge:
+data[0] = avail.left();
+data[1] = 0;
+break;
+case TopEdge:
+data[0] = avail.top();
+data[1] = 1;
+break;
+case RightEdge:
+data[0] = avail.right();
+data[1] = 2;
+break;
+case BottomEdge:
+data[0] = avail.bottom();
+data[1] = 3;
+default:
+break;
+}
+
+if (location == Desktop || location == Floating) {
+XDeleteProperty(dpy, id, atom);
+} else {
+XChangeProperty(dpy, id, atom, atom, 32, PropModeReplace,
+reinterpret_castunsigned char *(data.data()), data.size());
+}
+#endif
+}
+
+}
+
+}
Index: dialog.cpp
===
--- dialog.cpp (revision 1002551)
+++ dialog.cpp (working copy)
@@ -49,6 +49,7 @@
#include plasma/private/extender_p.h
#include plasma/framesvg.h
#include plasma/theme.h
+#include plasma/windoweffects.h
#ifdef Q_WS_X11
#include X11/Xlib.h
@@ -526,6 +527,19 @@
emit dialogVisible(true);
}
+void Dialog::focusInEvent(QFocusEvent *event)
+{
+Q_UNUSED(event)
+
+if (d-view) {
+d-view-setFocus();
+}
+
+if (d-graphicsWidget) {
+d-graphicsWidget-setFocus();
+}
+}
+
void Dialog::moveEvent(QMoveEvent *event)
{
Q_UNUSED(event)
@@ -559,37 +573,26 @@
return;
}
-#ifdef Q_WS_X11
-//set again the atom, the location could have changed
-QDesktopWidget *desktop = QApplication::desktop();
-QRect avail = desktop-availableGeometry(desktop-screenNumber(pos()));
+Location location = Desktop;
-Display *dpy = QX11Info::display();
-Atom atom = XInternAtom( dpy, _KDE_SLIDE, False );
-QVarLengthArraylong, 1024 data(2);
-
switch (direction) {
+case Down:
+location = BottomEdge;
+
Re: panels and popups sliding effect
On Sunday 26 July 2009, Marco Martin wrote: i'm really on the fence on where to put this and how to call it. Becasue if we put other stuff like that like the taskbar thumbnails and the glow effect they wouldn't have much to do with animation, and i'm kinda wondering if plasma is the right namespace/lib for that, hmm.. Plasma::WindowEffects as a name space in libplasma is just fine i think. cons: * it's not really 100% in the right theme for libplasma (a components-on- canvas library) * it's potentially useful to many other applications that otherwise wouldn't need libplasma pros: * it allows us to use it in libplasma (Dialog, ToolTip, etc) * it allows us to use Plasma defines, such as location (which putting it in kdeui, for instance, wouldn't); perhaps this could be worked around, though * from libplasma all plasma shells and plugins can easily take advantage of this functionality so not perfect, but i don't see a better place for it. let's put it in trunk, start using it and see if something better doesn't become evident before 4.4.0 is released. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Sunday 26 July 2009, Aaron J. Seigo wrote: On Sunday 26 July 2009, Marco Martin wrote: i'm really on the fence on where to put this and how to call it. Becasue if we put other stuff like that like the taskbar thumbnails and the glow effect they wouldn't have much to do with animation, and i'm kinda wondering if plasma is the right namespace/lib for that, hmm.. Plasma::WindowEffects as a name space in libplasma is just fine i think. cons: * it's not really 100% in the right theme for libplasma (a components-on- canvas library) * it's potentially useful to many other applications that otherwise wouldn't need libplasma pros: * it allows us to use it in libplasma (Dialog, ToolTip, etc) * it allows us to use Plasma defines, such as location (which putting it in kdeui, for instance, wouldn't); perhaps this could be worked around, though * from libplasma all plasma shells and plugins can easily take advantage of this functionality so not perfect, but i don't see a better place for it. let's put it in trunk, start using it and see if something better doesn't become evident before 4.4.0 is released. ok, so for now WindowEffects is in :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Friday 24 July 2009, Aaron J. Seigo wrote: On Thursday 23 July 2009, Marco Martin wrote: animateWindow(winId, Animation, Location); the same for the highlight windows and other xatom based affects as well. animateWindow is a bit generic of a name given that, but i think it's completely the right idea/direction. not sure animator is the right place for other effects like highlight windows, taskbar thumbnails and things like that what about a small library (just statics probably) in workspace to deal with this stuff? KWindowSystemExtra? iirc in the plasma-kwin meeting at akademy Lubos mentioned to put them directly in KWindowsystem? but perhaps is too kde-specific stuff? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On 7/24/09, Marco Martin notm...@gmail.com wrote: On Friday 24 July 2009, Aaron J. Seigo wrote: On Thursday 23 July 2009, Marco Martin wrote: animateWindow(winId, Animation, Location); the same for the highlight windows and other xatom based affects as well. animateWindow is a bit generic of a name given that, but i think it's completely the right idea/direction. not sure animator is the right place for other effects like highlight windows, taskbar thumbnails and things like that what about a small library (just statics probably) in workspace to deal with this stuff? KWindowSystemExtra? iirc in the plasma-kwin meeting at akademy Lubos mentioned to put them directly in KWindowsystem? but perhaps is too kde-specific stuff? added a setSlidingWindow (not animatewindow or something like this because it doesn't actually animates, it just tells the window it -can- animate) function to animator, the thing becomes a lot cleaner, but anyways i think that a different (even non plasma) library would be better Cheers, Marco Martin Cheers, Marco Martin windoweffectanimartor.diff Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Friday 24 July 2009, Marco Martin wrote: what about a small library (just statics probably) in workspace to deal with this stuff? KWindowSystemExtra? the code needs to be accessible from libplasma though so that e.g. PopupApplet can animate its stuff. that's why i suggested Animator. a Plasma::WindowEffects namespace would be fine as well imo. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Tuesday 21 July 2009, Marco Martin wrote:
On Tuesday 21 July 2009, Lucas Murray wrote:
On Tue, Jul 21, 2009 at 11:59 AM, Lucas
Murraylmur...@undefinedfire.com
wrote:
The property would look something like: _KDE_SLIDE = {x1, y1, x2, y2,
direction} where the two coordinates must be either exactly horizontal
or vertical and the direction is 0 for coming from the top/left and 1
is for coming from the bottom/right when the window appears. When the
window is closed it goes back the way it came (Changing the property
while the window is mapped allows you to make the window slide to a
different location on close). The coordinates specify the clipping
geometry--it starts at the coords and ends at the (Xinerama) screen
edge in the direction that the window specified.
Two coordinates are not required, it's possible with just one value.
Thus the property would be {coord, direction} where `direction` is 0 =
left, 1 = right, 2 = top, 3 = bottom and `coord` specifies either the
starting X or Y position, depending on the direction.
Here we go, now the direction and the starting points are specified by the
_KDE_SLIDE atom.
and plasma::dialog sets it, it seems to work quite good.
for plasma side:
is the custom anim code in Dialog and Panel to be removed? or should be
there some kind of fallback for Compiz/Windows/whatever?
so, is this patch ok? can go in? there are important chages to do?
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Thursday 23 July 2009, Aaron J. Seigo wrote: On Tuesday 21 July 2009, Marco Martin wrote: is the custom anim code in Dialog and Panel to be removed? or should be yes, i think it can be removed. what i don't like about these patches is that they manipulate the xatoms directly. it's fairly ugly code and it gets copied in various places, requiring changes made to all of them when/if we change how this is done (as we just have) perhaps we should add to Plasma::Animator a method for animating one or more windows? then it's completely hidden from the individual applets using this stuff. if kwin changes, we can change our code easily. if we wish to do it differently in other windowing systems or managers, we can.. etc. I like the Animator idea probably it should be enough animateWindow(winId, Animation, Location); Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Thursday 23 July 2009, Marco Martin wrote: animateWindow(winId, Animation, Location); the same for the highlight windows and other xatom based affects as well. animateWindow is a bit generic of a name given that, but i think it's completely the right idea/direction. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Tuesday 21 July 2009, Aaron J. Seigo wrote: On Monday 20 July 2009, Marco Martin wrote: windows should be clipped to look as they come from the panel, and not slide over it, is there another way to achieve that? maybe if it slides under the panel could make sense, not sure,hmm that'll look ugly with translucent panels. but Lucas' solution can prevent that, really. yeah, but i think clipping is still needed -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Tuesday 21 July 2009, Lucas Murray wrote:
On Tue, Jul 21, 2009 at 11:59 AM, Lucas Murraylmur...@undefinedfire.com
wrote:
The property would look something like: _KDE_SLIDE = {x1, y1, x2, y2,
direction} where the two coordinates must be either exactly horizontal
or vertical and the direction is 0 for coming from the top/left and 1
is for coming from the bottom/right when the window appears. When the
window is closed it goes back the way it came (Changing the property
while the window is mapped allows you to make the window slide to a
different location on close). The coordinates specify the clipping
geometry--it starts at the coords and ends at the (Xinerama) screen
edge in the direction that the window specified.
Two coordinates are not required, it's possible with just one value.
Thus the property would be {coord, direction} where `direction` is 0 =
left, 1 = right, 2 = top, 3 = bottom and `coord` specifies either the
starting X or Y position, depending on the direction.
Here we go, now the direction and the starting points are specified by the
_KDE_SLIDE atom.
and plasma::dialog sets it, it seems to work quite good.
for plasma side:
is the custom anim code in Dialog and Panel to be removed? or should be there
some kind of fallback for Compiz/Windows/whatever?
Cheers,
Marco Martin
Index: slidingpopups/slidingpopups.cpp
===
--- slidingpopups/slidingpopups.cpp (revision 0)
+++ slidingpopups/slidingpopups.cpp (revision 0)
@@ -0,0 +1,180 @@
+/
+ KWin - the KDE window manager
+ This file is part of the KDE project.
+
+Copyright (C) 2009 Marco Martin notm...@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/.
+*/
+
+#include slidingpopups.h
+
+#include kdebug.h
+
+namespace KWin
+{
+
+KWIN_EFFECT( slidingpopups, SlidingPopupsEffect )
+
+SlidingPopupsEffect::SlidingPopupsEffect()
+{
+mAtom = XInternAtom( display(), _KDE_SLIDE, False );
+effects-registerPropertyType( mAtom, true );
+// TODO hackish way to announce support, make better after 4.0
+unsigned char dummy = 0;
+XChangeProperty( display(), rootWindow(), mAtom, mAtom, 8, PropModeReplace, dummy, 1 );
+}
+
+SlidingPopupsEffect::~SlidingPopupsEffect()
+{
+XDeleteProperty( display(), rootWindow(), mAtom );
+effects-registerPropertyType( mAtom, false );
+}
+
+void SlidingPopupsEffect::prePaintScreen( ScreenPrePaintData data, int time )
+{
+if( !mAppearingWindows.isEmpty() || !mDisappearingWindows.isEmpty() )
+data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;
+effects-prePaintScreen( data, time );
+}
+
+void SlidingPopupsEffect::prePaintWindow( EffectWindow* w, WindowPrePaintData data, int time )
+{
+if( mAppearingWindows.contains( w ) )
+{
+mAppearingWindows[ w ].addTime( time );
+if( mAppearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+mAppearingWindows.remove( w );
+}
+else if( mDisappearingWindows.contains( w ) )
+{
+mDisappearingWindows[ w ].addTime( time );
+if( mDisappearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+{
+mDisappearingWindows.remove( w );
+w-unrefWindow();
+}
+}
+effects-prePaintWindow( w, data, time );
+}
+
+void SlidingPopupsEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData data )
+{
+bool animating = false;
+bool appearing = false;
+QRegion clippedRegion = region;
+
+if( mAppearingWindows.contains( w ) )
+{
+appearing = true;
+animating = true;
+}
+else if( mDisappearingWindows.contains( w ) )
+{
+appearing = false;
+animating = true;
+}
+
+
+if( animating )
+{
+const qreal progress = appearing?(1 - mAppearingWindows[ w ].value()):mDisappearingWindows[ w ].value();
+const int start = mWindowsData[ w ].start;
+
+switch (mWindowsData[ w ].from)
+{
+case West:
+data.xTranslate += (start - w-width()) * progress;
+clippedRegion =
Re: panels and popups sliding effect
On Monday 20 July 2009, Martin Gräßlin wrote: IIRC we said that adding a special window type would be better. That one would of course be outside netwm - nevertheless could be added to netwm later on. hm.. would this replace the usual window type for the window, or can a window have more than one type? i ask because we want this effect for panels and for popup dialogs and possibly in future for other types of windows. if the window type is exclusive, this may be not flexible enough? would simply setting some other atom on the window be possible and sensible? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Monday 20 July 2009, Martin Gräßlin wrote:
Am Montag 20 Juli 2009 18:18:48 schrieb Marco Martin:
Hi all,
At the plasmakwin bof at akademy one of the things we talked about was a
new effect that can make popups and panels appear with a slide animation.
today i decided to give it a try here is the result, it seems to work
quite well.
great :-D
I just had a look on the code and it looks good. I will try it later on.
Some things I noticed:
yeah, some whoopsie, the attached patch corrects it
* in postPaintWindow you probably want to trigger repaints for
disappearing windows as well. And you could trigger a full repaint for the
complete screen. Well does not really matter as you set
PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS
* Resetting the curve shape in each frame looks like overkill :-)
indeed :)
by the way, i did copy the thing from scale in effect, that will have to be
corrected as well :p
* Do you really need the clippedRegion?
windows should be clipped to look as they come from the panel, and not slide
over it, is there another way to achieve that?
maybe if it slides under the panel could make sense, not sure,hmm
in the experiments i done they always looked as if the windows are always
painted over the panel..
* when the window get's closed you have to w-refWindow(). When your
animation finishes for that window you have to w-unrefWindow(). Without
that you cannot use a window which has been closed. That code only worked
because you had fade effect activated with same animation time ;-)
oh, good to know :)
* would excluding minimized windows from closing make sense? When
restricting to only Plasma dialogs it probably doesn't matter.
Now it applies to every window and this is of course bad++, what is
needed is some way to apply the thing only on windows we want.
that could be the dock type and, if it's on all of popups is way too
much, so what we need? an atom to apply on windows we need? (for us
basically just Plasma::Dialog)
or, a new window type? (would it be a type outside Netwm? is this
acceptable?) anyways, how does this patch look? is on the right track?
IIRC we said that adding a special window type would be better. That one
would of course be outside netwm - nevertheless could be added to netwm
later on.
yep, i'm wondering if we could want the effect for other types too, hmm
adding (another) new type could also solve my issue with the netbook shell,
where kwin thinks that window is fullscreen just because has the full size but
not the fullscreen flag, i'm knda hesitant to add non netwm types but yeah, if
they aren't up to the job why not :D
--
Marco Martin
Index: slidingpopups/slidingpopups.cpp
===
--- slidingpopups/slidingpopups.cpp (revision 0)
+++ slidingpopups/slidingpopups.cpp (revision 0)
@@ -0,0 +1,176 @@
+/
+ KWin - the KDE window manager
+ This file is part of the KDE project.
+
+Copyright (C) 2009 Marco Martin notm...@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/.
+*/
+
+#include slidingpopups.h
+
+#include kdebug.h
+
+namespace KWin
+{
+
+KWIN_EFFECT( slidingpopups, SlidingPopupsEffect )
+
+void SlidingPopupsEffect::prePaintScreen( ScreenPrePaintData data, int time )
+{
+if( !mAppearingWindows.isEmpty() || !mDisappearingWindows.isEmpty() )
+data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;
+effects-prePaintScreen( data, time );
+}
+
+void SlidingPopupsEffect::prePaintWindow( EffectWindow* w, WindowPrePaintData data, int time )
+{
+if( mAppearingWindows.contains( w ) )
+{
+mAppearingWindows[ w ].setCurveShape( TimeLine::EaseOutCurve );
+mAppearingWindows[ w ].addTime( time );
+if( mAppearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+mAppearingWindows.remove( w );
+}
+else if( mDisappearingWindows.contains( w ) )
+{
+mDisappearingWindows[ w ].setCurveShape( TimeLine::EaseOutCurve );
+mDisappearingWindows[ w ].addTime( time );
+if( mDisappearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+mDisappearingWindows.remove( w );
+}
+effects-prePaintWindow(
Re: panels and popups sliding effect
On Monday 20 July 2009, Marco Martin wrote:
On Monday 20 July 2009, Martin Gräßlin wrote:
Am Montag 20 Juli 2009 18:18:48 schrieb Marco Martin:
Hi all,
At the plasmakwin bof at akademy one of the things we talked about was
a new effect that can make popups and panels appear with a slide
animation. today i decided to give it a try here is the result, it
seems to work quite well.
great :-D
I just had a look on the code and it looks good. I will try it later on.
Some things I noticed:
yeah, some whoopsie, the attached patch corrects it
oops, this is the correct one :D
--
Marco Martin
Index: slidingpopups/slidingpopups.cpp
===
--- slidingpopups/slidingpopups.cpp (revision 0)
+++ slidingpopups/slidingpopups.cpp (revision 0)
@@ -0,0 +1,179 @@
+/
+ KWin - the KDE window manager
+ This file is part of the KDE project.
+
+Copyright (C) 2009 Marco Martin notm...@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/.
+*/
+
+#include slidingpopups.h
+
+#include kdebug.h
+
+namespace KWin
+{
+
+KWIN_EFFECT( slidingpopups, SlidingPopupsEffect )
+
+void SlidingPopupsEffect::prePaintScreen( ScreenPrePaintData data, int time )
+{
+if( !mAppearingWindows.isEmpty() || !mDisappearingWindows.isEmpty() )
+data.mask |= PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS;
+effects-prePaintScreen( data, time );
+}
+
+void SlidingPopupsEffect::prePaintWindow( EffectWindow* w, WindowPrePaintData data, int time )
+{
+if( mAppearingWindows.contains( w ) )
+{
+mAppearingWindows[ w ].addTime( time );
+if( mAppearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+mAppearingWindows.remove( w );
+}
+else if( mDisappearingWindows.contains( w ) )
+{
+mDisappearingWindows[ w ].addTime( time );
+if( mDisappearingWindows[ w ].value() 1 )
+data.setTransformed();
+else
+{
+mDisappearingWindows.remove( w );
+w-unrefWindow();
+}
+}
+effects-prePaintWindow( w, data, time );
+}
+
+void SlidingPopupsEffect::paintWindow( EffectWindow* w, int mask, QRegion region, WindowPaintData data )
+{
+bool animating = false;
+bool appearing = false;
+QRegion clippedRegion = region;
+
+if( mAppearingWindows.contains( w ) )
+{
+appearing = true;
+animating = true;
+}
+else if( mDisappearingWindows.contains( w ) )
+{
+appearing = false;
+animating = true;
+}
+
+
+if( animating )
+{
+qreal progress = appearing?(1 - mAppearingWindows[ w ].value()):mDisappearingWindows[ w ].value();
+
+switch (mWindowPositions[ w ])
+{
+case West:
+data.xTranslate -= w-width() * progress;
+clippedRegion = clippedRegion.subtracted(QRegion(w-x()-w-width(), w-y(), w-width(), w-height()));
+break;
+case North:
+data.yTranslate -= w-height() * progress;
+clippedRegion = clippedRegion.subtracted(QRegion(w-x(), w-y() - w-height(), w-width(), w-height()));
+break;
+case East:
+data.xTranslate += w-width() * progress;
+clippedRegion = clippedRegion.subtracted(QRegion(w-x()+w-width(), w-y(), w-width(), w-height()));
+break;
+case South:
+default:
+data.yTranslate += w-height() * progress;
+clippedRegion = clippedRegion.subtracted(QRegion(w-x(), w-y() + w-height(), w-width(), w-height()));
+}
+}
+
+effects-paintWindow( w, mask, clippedRegion, data );
+}
+
+void SlidingPopupsEffect::postPaintWindow( EffectWindow* w )
+{
+if( mAppearingWindows.contains( w ) || mDisappearingWindows.contains( w ) )
+w-addRepaintFull(); // trigger next animation repaint
+effects-postPaintWindow( w );
+}
+
+void SlidingPopupsEffect::windowAdded( EffectWindow* c )
+{
+if( c-isOnCurrentDesktop())
+{
+mAppearingWindows[ c ].setDuration( animationTime( 250 ));
+mAppearingWindows[ c
Re: panels and popups sliding effect
Am Monday 20 July 2009 schrieb Marco Martin: adding (another) new type could also solve my issue with the netbook shell, where kwin thinks that window is fullscreen just because has the full size but not the fullscreen flag afaik that's a workaround for old apps that are not NETWM compliant, but err... häh? if it's an undecorated fullsize window - what's wrong with it being treated as fullscreen? you can keep it below if you want or rather tag it as desktop type... (i.e. what do you want to achieve) and if there's a deco, there shouldn't be a problem at all, just maximize it. Regards, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Monday 20 July 2009, Thomas Lübking wrote: Am Monday 20 July 2009 schrieb Marco Martin: adding (another) new type could also solve my issue with the netbook shell, where kwin thinks that window is fullscreen just because has the full size but not the fullscreen flag afaik that's a workaround for old apps that are not NETWM compliant, but err... häh? if it's an undecorated fullsize window - what's wrong with it being treated as fullscreen? you can keep it below if you want or rather tag it as desktop type... (i.e. what do you want to achieve) and if there's a deco, there shouldn't be a problem at all, just maximize it. yeah, it's a quite unusual thing that is a bit perverse. it is a full size, frameless window, that contains the desktop of the thing.. now, i don't set the window as a desktop because i want it to show up in the present window effect and i want to let it to go over other windows. but the fact is that i have also a traditional panel, that is a dock, and always on top window (i have also other always on top windows, that are the popups of stuffs like the calendar) what it happens is the following thing: the panel will always stay in front of the desktop if another window is selected as soon as the desktop window gets active, it covers the panel (that is always on top, but those can be covered by fullscreen windows) soo, at the moment the window is kept -one- pixel smaller, lol :) Regards, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Tue, Jul 21, 2009 at 4:06 AM, Marco Martinnotm...@gmail.com wrote:
oops, this is the correct one :D
I thought I mentioned that for this effect to work the way you want it
you would apply an X property on the window before mapping it.
The property would look something like: _KDE_SLIDE = {x1, y1, x2, y2,
direction} where the two coordinates must be either exactly horizontal
or vertical and the direction is 0 for coming from the top/left and 1
is for coming from the bottom/right when the window appears. When the
window is closed it goes back the way it came (Changing the property
while the window is mapped allows you to make the window slide to a
different location on close). The coordinates specify the clipping
geometry--it starts at the coords and ends at the (Xinerama) screen
edge in the direction that the window specified.
This would prevent the effect from affecting windows it's not supposed
to and will allow the window to appear from any place it wants to,
even if it's far away from it's final position.
--
Lucas Murray :: http://www.undefinedfire.com
GPG Fingerprint: 0B88 499E 3F5B 1405 D952 258A AD90 B4F5 90B6 3534
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Tue, Jul 21, 2009 at 11:59 AM, Lucas Murraylmur...@undefinedfire.com wrote:
The property would look something like: _KDE_SLIDE = {x1, y1, x2, y2,
direction} where the two coordinates must be either exactly horizontal
or vertical and the direction is 0 for coming from the top/left and 1
is for coming from the bottom/right when the window appears. When the
window is closed it goes back the way it came (Changing the property
while the window is mapped allows you to make the window slide to a
different location on close). The coordinates specify the clipping
geometry--it starts at the coords and ends at the (Xinerama) screen
edge in the direction that the window specified.
Two coordinates are not required, it's possible with just one value.
Thus the property would be {coord, direction} where `direction` is 0 =
left, 1 = right, 2 = top, 3 = bottom and `coord` specifies either the
starting X or Y position, depending on the direction.
--
Lucas Murray :: http://www.undefinedfire.com
GPG Fingerprint: 0B88 499E 3F5B 1405 D952 258A AD90 B4F5 90B6 3534
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panels and popups sliding effect
On Monday 20 July 2009, Marco Martin wrote: windows should be clipped to look as they come from the panel, and not slide over it, is there another way to achieve that? maybe if it slides under the panel could make sense, not sure,hmm that'll look ugly with translucent panels. but Lucas' solution can prevent that, really. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
