[PATCH] Animations enable/disable system wide

Robert Knight robertknight at gmail.com
Sat Feb 16 15:27:05 GMT 2008


> Well, the only difference is that with the one, you have ~4 states you need
> to hard-code against, different applications interpreting the states
> differently.

It is feasible to test all of the main KDE applications against 3 or 4
different settings.  If you have checkboxes for each capability then
this becomes 2^N different states where N is the number of options.

> As whatever is decided upon now will stay around for KDE4's
> full life-span, the groundwork should be done right.

Right.  One thing I learned over the past couple of years is that it
is much easier to add options rather than take them out.  This can
quickly lead to over-complex user interfaces which make it hard for
users to comprehend them and achieve their basic goals.

Regards,
Robert.

On 16/02/2008, Richard Hartmann <richih.mailinglist at gmail.com> wrote:
> On Feb 16, 2008 2:20 PM, Robert Knight <robertknight at gmail.com> wrote:
>
>
> > This is about performance, "need high contrast" is an accessibility
> > issue.  "wants to save battery" is a dynamic state which is already
> > available though Solid.
>
> Not quite, Aaron brought up gradients, which could also reach into this.
> I see what you mean, though. Could it make sense to try an unify those
> things?
>
>
> > That makes it more complicated all of a sudden.  Right now I'd suggest
> > keeping it simple and getting it working where it matters, eg. as per
> > Aaron's pre-defined list above.
>
> Well, the only difference is that with the one, you have ~4 states you need
> to hard-code against, different applications interpreting the states
> differently.
> If things went more along your KDE3-style slider suggestion, one would
> need more fine-grained states, anyway. Those could then be used as basis
> for super-sets. Implementing the background en detail and just offering
> basic options to the end-user would make the most sense to me if time is
> an issue. As whatever is decided upon now will stay around for KDE4's
> full life-span, the groundwork should be done right.
>
>
> Richard
>




More information about the kde-core-devel mailing list