[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Code transitions - Theme transitions
From:       Rafael =?utf-8?b?RmVybsOhbmRleiA=?= =?utf-8?b?TMOzcGV6?= <ereslibre () kde ! org>
Date:       2008-11-16 23:42:24
Message-ID: 20081117084826.36fsqxj85ws4kwcc () mail ! kollide ! net
[Download RAW message or body]

This message is in MIME format.


Hi all,

I am pretty sure you remember the class Mathias Kretz did start for widget
transitions: KFadeWidgetEffect. It had serious performance problems that wer=
e
fixed later by me, fully basing the code on the work done by Fredrik H=C3=B6=
glund
on KFileItemDelegate.

My question here is clear: after the performance problem was 'fixed', I did
add transitions for paged dialogs (for instance, most of the configuration
dialogs). The Phonon KCM also uses it when you switch between sound devices.

I have installed bespin style for trying it out. It contains lots, lots of
animations. One of them is when you switch between widgets (on a stacked
layout or something like that), since it transitions when you change tabs. I
have the feeling (haven't tested it though) that when I switch between confi=
g
pages, it is somehow "slow", so I think maybe they are both trying to do the
same transition.

So I want to both ask and suggest something.

- Who should take care of asking KGlobalSettings::graphicEffectsLevel(), the
style or someone else on our code ?

If we decide that some part of our code (as it is right now), we should make
it very clear to the style that it shouldn't alter the settings that have be=
en
set somewhere else (at the moment there is no way of graphically change the
graphicEffectsLevel, but it will be).

I ask this mainly because I have read on IRC that QTreeView::setAnimated()
seems to work fine and is nice. I was tempted to write the attached patch, a=
nd
later I wondered: "should this be really done by kstyle?".

On the other hand, seems to be natural, because adding the same options for
every style that will be developed is not a nice thing. Imagine a "fade
transitions" on every style configuration dialog.

So, summing up:

- Styles in general should ask KGlobalSettings::graphicEffectsLevel() if the=
y
provide animations.

- What animations should they provide for not hitting other kind of animatio=
ns
set at other level (e.g. KStyle or widget level [like KFadeWidgetEffect]) ?

- How are we going to tell styles what animations should they NOT provide
because they hit some other animations set at other level ?


Regards,
Rafael Fern=C3=A1ndez L=C3=B3pez.

["kdelibs.diff" (text/x-patch)]

diff --git a/kdeui/kernel/kstyle.cpp b/kdeui/kernel/kstyle.cpp
index 983abef..e9d858e 100644
--- a/kdeui/kernel/kstyle.cpp
+++ b/kdeui/kernel/kstyle.cpp
@@ -50,7 +50,7 @@
 #include <QtCore/QCache>
 #include <QtCore/QEvent>
 #include <QtCore/QVariant>
-#include <QtGui/QAbstractItemView>
+#include <QtGui/QTreeView>
 #include <QtGui/QApplication>
 #include <QtGui/QDialogButtonBox>
 #include <QtGui/QFormLayout>
@@ -399,6 +399,10 @@ void KStyle::polish(QWidget *w)
     // Enable hover effects in all itemviews
     if (QAbstractItemView *itemView = qobject_cast<QAbstractItemView*>(w) ) {
         itemView->viewport()->setAttribute(Qt::WA_Hover);
+
+        if (QTreeView *treeView = qobject_cast<QTreeView*>(w)) {
+            treeView->setAnimated(KGlobalSettings::graphicEffectsLevel() & \
KGlobalSettings::SimpleAnimationEffects); +        }
     }
 
     QCommonStyle::polish(w);



[prev in list] [next in list] [prev in thread] [next in thread]