<br><div class="gmail_quote">On 5 August 2010 17:51, Thomas Lübking <span dir="ltr"><<a href="mailto:thomas.luebking@web.de">thomas.luebking@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not really sure about the meaning of "accidental clicks", but 900ms is a<br>
quite long time.<br><div class="im"></div></blockquote><div>Current default toolbar has a great feature letting users to drag songs to do previous/next track thing. On some touchpads its realitviely easy to drag too far away (one of the reasons I use USB mouse), thus getting over volume control. In this case it's sometimes possible to click on it accidentally. But its just a edge case, and animated increase (interesting idea, Thomas :)) would solve this in a proper way. (0.9s was just an example time)<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> * displaying volume level in the centre of wheel, while hovering "active"<br>
> area, so giving additional feedback what wil happen if you click here<br>
</div>You mean when hovering the ring area (currently only hinted by the cursor<br>
shape)<br>
....<br>
I'd prefer to remove the tooltip and use the button area instead </blockquote><div>+1 for button area<br> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>The eardrum thing sounds resonable ;-)<br>
I'd however suggest to start an "animated" volume increase nevertheless (as<br>
long as the mb is down) @ eg. 1%/50ms resulting in 20%/second<br></blockquote><div>As I've said, great idea + using a some sort of log (time) multiplier to add some acceleration would be very intuitive way (sec<br></div>
<div> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Notice that aside this (the coolbar draft includes a similar approach - the<br>
slider animatedly slides out of the icon and replaces the other content, don't<br>
think i've ever commited that, though) the _severe_ drawback of hover<br>
interfaces is that they o not work with "absolute" input devices like<br>
touchscreens or pens (in absolute, ie. not mouse emulating, mode)<br>
<br>
This is not a big deal for sheer feedback, BUT if the functionality of an<br>
elemene relies on this, one explicitly excludes a group of users.<br></blockquote><div>As tablets getting into marker quite fast, is it really good idea to make them eliminated?<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The flickeraffinity of hover sensitive elements (as the other Thomas pointed)<br>
is usually dealt with a timer and distance check (have a look at the coolbar<br>
in smaller sizes - that is committed ;-)<br>
This basically allows an unprecise movement "along" the slider and not really<br>
a problem.<br></blockquote><div>I'll take a look, thanks for pointing me. <br></div><div><br>p.s. will it be possible to run Amarok (or any other KDE app) on MeeGo/Android/Any other linux based mobile platform? <br><br>
Lukas<br></div></div>