[Panel-devel] kalming kickoff
Robert Knight
robertknight at gmail.com
Mon Nov 12 12:40:11 CET 2007
> though at the same time i'm not going to put up
> kindly with svn commit revert wars.
Right, and I maintain that the use of "bold" rendering to denote the
highlighted item instead of filling the background with the normal
blue highlight colour is difficult to use because it makes the area on
which you have to concentrate to determine the selected item much
smaller. I realised when attempting to use the "bold" rendering that
I don't actually look at the text of the item in the an item-view when
trying to select it, I just recognise where the "blue selection blob"
needs to appear and move the mouse until the blob is in the right
position (first a big movement to get to the general section of the
view then small movements to get the right item).
At least one other person on IRC echoed my opinion, and to be honest,
I should have thrown the floor open to comments from other users
earlier. I am doing that now.
Back to your the main subject of your post, thanks for the patch.
There is quite a lot to look at there. I'll do that when I get back
from lectures later today.
On 12/11/2007, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday 11 November 2007, Aaron J. Seigo wrote:
> > - lighten the icons of non-hovered items
> > - only paint subtitle text when the item is highlighted
> > - lighten device usage meters when not highlighted
>
> btw, these state changes ought to be animated with 1-2 tweener frames,
> easily
> accomplished by adjusting alpha in overlay rects. i haven't looked into how
> to do this most effectively, however, so as to avoid repainting more than
> necessary, having nice in-outs (so no "jump straight to neutral state on
> leave"), etc ... performance is my big concern on this one.
>
> --
> 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 Trolltech
>
More information about the Panel-devel
mailing list