[PATCH] Animations enable/disable system wide

[Rafael Fernández López]

Hi all,

> > 1)  This is implemented as a binary yes/no option.  Will that be
> > flexible enough?
>
> probably not.

Agreed.

> > Animations in a small area can be typically done
> > even on fairly slow machines.
>
> it's not just slow machines, of course, but also network sessions (see
> below for more on that)

Agreed.

> > 2)  I don't think the meaning of the checkbox text and tooltips is clear.

Yeah, I constantly ask for better names, but no one has come up yet.

> > An alternative approach might be to have a slider with a number of
> > levels for the performance - with the simplest and least costly at the
> > top and the most expensive at the bottom.  This approach was used in
>
> i wonder how many users will actually have the knowledge to pick an
> appropriate setting. perhaps it would be better to simply provide a set of
> use cases in a drop down box, e.g.:
>
> Optimize graphical effects for: [ Modern desktop / laptop system
> 			  [ Low performance system
> 			  [ Remote desktop or thin client
> 			  [ Mobile device
>
> the exact entries are pulled out of my posterior as i was typing this, but
> i think giving the user a set of options that map to the actual use cases
> might be a lot easier to figure out.

I really prefer the drop down box to the slider.

> > - Minimal use of complex static 2D (eg. gradients), no animations
> > - Use of complex static 2D (eg. gradients), no animations
>
> well, gradients are less of an issue than animations on thin client
> systems, but more of an issues on poorly supported hardware or where there
> are accessiblity conerns.
>
> use of gradients is actually fairly orthogonal to animation, since you may
> be able to handle animations just fine but be using a low colour display.
> the operator may also have a vision problem that requires high contrast
> (something gradients are often used to avoid). in those cases, you don't
> want gradients and complex SVGs, but you do want to keep the anims.
>
> > - As above, but with simple animations (ie. Qt's animations)
> > - As above, but with more sophisticated 2D animations (eg. which is
> > what your patch allows)

Well my patch will enable/disable all animations those from Qt and those that we 
added widespread to KDE at different points.

> outside of OpenGL (which AFAIK is relatively easy to tell programtically
> whether it's being handled in software or hardware), it can be considerably
> more difficult to know when something is hardware accelerated due to the
> variance between drivers, not to mention x.org acceleration architecture
> being used and the toolkit (and version of it) being used in the
> application (since different versions of different toolkits work better or
> worse with different accel systems). not a pretty sight =)
>
> if there is an easy way to cut through that gordian knot, perhaps one of
> the people more knowledgeable of the details of X11 might fill us in, but
> afaik that's the current state of things.
>
> also note that these settings should probably also have a modifier for when
> operating on (low?) battery power. now we're getting into power management,
> and the UI for that belongs elsewhere, but it should be possible to jack
> down the effects when i unplug my device or when my device starts running
> low on battery.

Yes, I have thought on that too... for now we can let the accessors and think la
ter on how can we modify this on runtime depending on the remaining enery (or go 
back to the normal settings if we for instance, were plugged on).

> Rafael's patch is a step in the right direction at least ... and now it's
> easy to find what needs to get fixed if we modify this API via an lxr
> search ;)

Before getting this into the public API, I think we should think well about this
, now changes should be thought twice before committing, specially in topics lik
e this one. I vote for changing the bool for an int, so we don't shoot ourselves 
on the feet.

How to call those methods, and what values the enum should have ?


Bye,
Rafael Fernández López.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080215/846e9da9/attachment.sig>