[LAD] Mouse/knob interaction

Tim E. Real termtech at rogers.com
Tue Sep 7 22:46:56 UTC 2010


On September 7, 2010 02:20:10 pm Gordon JC Pearce wrote:
> This is going to stir up a bit of discussion!
>
> Rotary knob GUI elements - should you move the mouse in a circle to
> operate them, or up and down?  What about side to side?
>
> Gordon MM0YEQ
>

A quick check of our MusE knobs shows it's circular motion.

Circular or linear doesn't really bother me too much,
 but if linear, then both up/down AND left/right should 
 operate the knob. I've seen some that do one but not the other.

However, I would like to share with you a 'patented' (he he) 
 technique I developed a long time ago:

When the mouse cursor goes to the edge of the screen you
 have no more movement, forcing you to pick up the mouse
 and go back to another position away from the screen edge
 and continue adjusting.

So here's what you do in the coding: 
When the control is clicked, you turn off the mouse cursor so that
 it is always INVISIBLE during adjustment, then you force it to the 
 CENTRE of the screen, and wait for some mouse movement.
When movement happens, you record how much it moved (delta)
 and use that to adjust the control's value (as usual), and then you 
 FORCE the mouse cursor right back to the CENTRE of the screen again,
 waiting for more mouse movement, and the whole process repeats.
Then when the control is un-clicked, you force the mouse cursor
 back to where it originally would have been, and turn it on again 
 so it's visible.

This way the mouse NEVER reaches the edge of the screen during 
 adjustment, although it may physically reach the edge of your desk.
However, with trackball mice you can keep on rolling and rolling, and
 the control keeps adjusting without end !

I used this technique in a 'spinbox' derivative which I call 'RollEdit'.
I hate reeeeally tiny spinbox up/down arrows, and waiting for them 
 to increment, don't you?
With my 'RollEdit', you simply click anywhere in the edit portion
 and start rolling, and rolling, and rolling, and the value keeps
 going and going and going... No mouse repositioning needed.

I also used it in 3D modelling apps: You click anywhere in a 'scene'
 and start rolling, and the zoom or viewer position (for example) 
 just keeps going and going. No visible mouse cursor to get in the way.
Excellent with trackballs !

(AutoDesk's 3D Studio at one time came close to this, but they
 messed it up by leaving the mouse cursor visible and making
 it 'wrap around' the edges of the screen. Like the game Asteroids, 
 very annoying.)

All of that work was in Windows and it was very complicated because
 you can receive multiple mouse movement messages for just one
 movement.

I've always wondered if Linux would be able to handle this technique
 better than in Windows. Never investigated yet. Opinions?

In MusE, when you click on any slider, even in the slider trough area,
 the mouse cursor is FORCED to the centre of the slider knob. 
I did this to help with automation, so that you could easily 'grab' the 
 slider knob even while it was in fast motion due to existing automation 
 movements.

Gotta go! Looks like bad thunderstorm here!

Thanks. Tim.





More information about the Linux-audio-dev mailing list