Code transitions - Theme transitions

[Thomas Lübking]

Am Monday 17 November 2008 schrieb Rafael Fernández López:
> I have the feeling (haven't tested it though) that when I switch between
> config pages, it is somehow "slow", so I think maybe they are both trying
> to do the same transition.
yes. i suppress the visual aspect of KFadeWidgetEffect,  but could not prevent 
it from doing the actual job (i.e. rendering widgets) until i read below...
=>-)

> 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 ?
whoever wants to provide some animation, i assume.

> 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 been set somewhere else
i don't (bespin doesn't link kde and usually i wouldn't change foreign 
settings myself, at least not w/o informing the user and/or pass him/her to 
the native UI dialog if there's)
i manipulate widgets though (styles are used to do that)
boyond that, you simply won't be able to prevent so. from doing so.

> I ask this mainly because I have read on IRC that QTreeView::setAnimated()
> seems to work fine and is nice.
i had e.g. problems w/ amarok and other treeviews w/ transparent (or not 
autofilling) bgs.
don't know if this is meanwhile fixed, but it seems as if the treeview 
internal anim code doesn't take this into account and just paints a plain base 
color bg during the anim - leads to flicker

> I was tempted to write the attached patch,
> and later I wondered: "should this be really done by kstyle?".
switching this particular thing on  in kstyle should be fine, because the 
worst thing would be non kstyle inheritors wouldn't take it into account and 
some inheritors might redisable it as "misfit" (just think of visual FX in 
e.g. Motif =D


radom thoughts:
1. visual FX are part of the look, the look is up to the style and it should 
thus somehow be taken into account regarding the outcome (currently 
KFadeWidgetEffect "only" crossfades, but bespin e.g. provides sliding or 
scanline fading what might fit a style's general laf much better)
2. whoever (inside KDE) wants to animate sth. should respect 
KGlobalSettings::graphicEffectsLevel att
3. there're two different kinds of UI animations:
a) integrated (like in qtreeview)
b) post applied (like fading two stacked widgets, hovering buttons, etc.)

"a"'s no big deal as everything happens inside the widget and outsiders aren't 
even informed on when to animate or have no access to data required to perform 
a usable (efficient) animation or at least know: "hey, there's this feature i 
(hopefully) can toggle and must prevent to interfere"

"b" is more problematic.
as it's (probably) not possible to test for interference without 
runtimebehaviour analysis (grettings to all M$ users and their able virus 
checkers ;-P) style and app can easily interfere at anytime, just because one 
implements a feature the other one already provided not knowing (from 
apps/widgets side) or because being unhappy with the current state (style 
side) (to state that clear: bespin was first! ;-P)

both approaches (app/widget vs. style implementation) have their drawbacks:

widget internal is the cleaner one but will remain a set of isles (think of 
the config pages, they're animated, all other stacks aren't, even worse would 
be: KPushButton: animated, QPushButton: not... :-( whoever sells this to joe 
user: it's not me ;-)
another drawback is the rather fixed look that may misfit the style (though 
this could be catched by asking styles to render transition states...)

styles
provide a more general hook (as they get touched to every widget during 
polishment),
have natural support for custom solutions (kstyle provides the infrastructure, 
so inheritors don't have to, but can reimplement) and
can take other needs into account (i chose to hide KFadeWidgetEffect, mainly 
because it lead to flicker as plain QWidget::render is (was?) unable to handle 
non plain bgs. it has (had?) trouble with scrollareas as well, btw.)

but the implementation isn't that clean (as they alter the apps and/or widgets 
behaviour without informing the widget) and thus a little tricky (QPointer is 
your frind, trust me)

as for commiunication between styles and apps/widgets:
you could add a property to the widget that says: "Do not animate me" and v.v. 
could ask a stylehint on whether a certain animation should be not performed 
(must be inverse, SH default return is false...)


Regards,
Thomas