[Gzz] Wheel turning options (was: Re: Ouch-- yes, cursor keys + wheel is a problem)

[Benja Fallenstein]

Tuukka wrote:
> Navigating with mouse has it's problem too: the connected nodes should 
> still be selectable before moving, if there are more nodes than the view 
> can show clearly.

True, good point. However, thinking about it, I don't think it's nearly 
as big a problem as keyboard.

> Click to select, another to move?

Ugh, no-- two clicks for almost every move, with mouse motion in 
between... Don't like.

> Scrollwheel to move 
> selection, left click to move?

For mouses with wheels, sounds very good. Here we can avoid the up/down 
problem by making wheeling in the right half of the window different 
from wheeling in the left half.

> Drag to move selection, click to move?

Also sounds very good-- direct interaction, turn the wheel using the 
mouse :-)

> > This is a severe bug. From a few minutes of trying, I am quite convinced 
> > that you cannot 'learn' to understand this behavior, because of the 
> > inconsistency between left and right. I don't know how to fix it :-( 
>
> One option is reverting back to the idea of two scroll controls: one for 
> left, one for right side. The sides could still scroll at the 
> same time, or it could be better if they didn't.

They should scroll together for reversability, i.e. hitting the reverse 
keys in reverse order brings you back where you've been.

> 1. Selection is only on one side at a time: if it's on left, pressing left 
> moves and pressing right switches selection to right. Meaning of up and 
> down keys depends on selection side.

Not good: a) It introduces a mode; b) it conflicts with reversability 
(after moving with 'Right', you'd have to press 'Left Left' to get back).

> 2. Selection is on both sides, and we assign corners of an arrow set 
> (numpad, joystick, "qezc" etc.) to intuitively work as clockwise and 
> counter-clockwise.

Having four doesn't make much sense when the two sides don't scroll 
independently-- you'd have two sets of two keys with the same functionality.

Maybe j/l for moving and u/o for rotating... (s/f and w/r on left hand). 
For the cursor keys, maybe left/right + modifier.

Another possibility is that up/down with modifier reverses their 
meaning, so that you'd press e.g. Ctrl when looking at the left side of 
the wheel.

Asko wrote:
> We could build a lego wheel controller O:-)

Yeah, that would be very cool. :-) But of course it doesn't solve the 
problem, since we need a keyboard way to turn the wheel.

Tuomas wrote:
> With 3D joystick, the rudder
> (i.e. rotating the stick along the stick's axis).

Same here. Sounds all very good, but we need keyboard interaction too.

Tuomas also wrote:
> On Fri, Feb 28, 2003 at 02:10:16PM +0200, Asko Soukka wrote:
[snip]
> > > "Clockwise / couterclockwise -keys" would be only renaming the current up 
> > > / down -keys ;)
>
> But the point is that they should not be vertical; more natural would be 
> right = clockwise, left = counterclockwise.

Yep.

> For instance, the keys '[' and ']'.

Please let's not by default use keys that are only conveniently 
reachable on English keyboards. (Also, the wheel turning keys need to be 
close to the arrows to make sense.)


(BTW, everybody, thanks for joining the discussion! Helps a lot to have 
the different ideas explored.)

I think I'm tending to designate w/r/u/o/7/9 as 'rotation' keys and in 
addition, Shift as rotation modifier. That is, pressing shift and a 
cursor key, including j/l/i/, etc, would rotate in that direction. For 
up/down, this would be a rotation around the x axis, while left/right 
rotate around z axis-- not sure whether up/down is useful. (Hmm. Could 
also use it to move along z axis.)

Opinions?

- Benja