Toolbox Brainstorming

[Aaron J. Seigo]

On Saturday 05 January 2008, Riccardo Iaconelli wrote:
> On Saturday 05 January 2008 20:18:25 Aaron J. Seigo wrote:
> > On Saturday 05 January 2008, Riccardo Iaconelli wrote:
> > > * Make the animations faster, they're way too slow now, and make the
> >
> > you could also patch the default animator to make moves 200ms (or even
> > 150?)
>
> Yeah, but I don't think this is the right solution. While animators should
> control the visual effects and the fps, they should not control the
> duration of the animation, that should be decided by the user (user as in
> developer).
>
> After all, not all moves/effects are the same, some may need a 500ms, while
> for some others a value of 50ms is much more appropriate.

besides the fact that there are very few effects that need 500ms, i'd really 
rather not open that pandora's box to people because more often than not they 
get it wrong. people of *think* they know what a good duration is, but 
usually they don't =)

> > that should be fairly easy. just iterate through the tools and ask for
> > their size, pick the largest or smallest (depending on the desired
> > effect) and use that.
>
> I'll do that later, not said that's impossible, that's why I added a todo.
> ;-)

indeed =)

> And apart from that, I think that visually it makes more sense, and it's
> indeed nicer, if it still stays there, littler. =)

except in situations (such as customized plasmas for various devices) where 
there may be no tools ever. in those cases we'll end up with a useless little 
blip which may be really odd.

> Oh, btw, random idea... what about a blob of plasma as background instead
> of the current gradient? :-)

heh. that'll *really* piss off the people who think it's already too "in your 
face" ;)

> Oh, and... because we've raised the toolbox-zooming issue... are we sure
> the toolbox must resize too? Why can't it remain fixed? It's a control

again, i'd like to see the toolbox not resize. (i've had this convo a few 
times now .. time to just code the damn thing so i don't have it again? ;)

> > patch 0002: obviously, this was done to mimic the Qt tooltips. but i
> > agree they should be faster. 300ms might be a bit fast; in kicker it was
> > 500ms and that seemed to work nicely.
>
> It could be the animation, but I can assure you, that having kicker and
> plasma's panel one on each other, the perceived delay is identical (at
> least when the animation starts). =)
> If you try it out you can see it's the right delay.

it's not about user perceived delay, it's about interaction mechanics. 300ms 
is pretty decent to detect an intentional mouse-over hover pause, but that's 
not particularly what tooltips are for. i went through this exact same dance 
with trial-and-error in kicker, btw.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080106/12fbb89b/attachment.pgp