[?][SUG][PL] Modifier + MouseWheel = Framestep Forwards/Backwards

[Guigui]

I love my mousewheel ! And while playing I am undecided wether to use it for the zoom in/out (default iirc), or for the frame stepping forward/backward. So why not use it for both ?

Ideally I think it'd be nice to be able to achieve the following settings :

* mousewheel up = zoom in
* mousewheel down = zoom out (this is already the case by default iirc)

* CTRL + mousewheel up = chosen number of frames step forward
* CTRL + mousewheel down = chosen number of frames step backward

[WillLem]

* CTRL + mousewheel up = chosen number of frames step forward
* CTRL + mousewheel down = chosen number of frames step backward

Hm. I agree, but this would mean treating the modifier keys only as modifiers. They could no longer be used on their own as single-fire key events.

I'm pretty sure a hack exists where you can use a modifier with itself (so, Ctrl+Ctrl) to get essentially the same behaviour as a single keypress, but I wonder if the key has to be held for a certain amount of time for that to work.

So, would anybody mind this being changed? Allow the modifiers to be used as modifiers, but no longer as hotkeys by themselves?

[Simon]

You don't have to remove single keybindings for this. The program should be able to fire event A on LCtrl-down, and later fire event B on ((LCtrl-held or RCtrl-held) + another-key-down).

LShift-down and LCtrl-down are handy in a left-hand layout.

Does the trouble arise from the design of the keybinding dialog?

-- Simon

[WillLem]

Does the trouble arise from the design of the keybinding dialog?

No. I don't think the program is able to distinguish between "keydown" and "keyheld", at least not currently.

Wouldn't "keyheld" necessarily have to fire "keydown" anyway? I could be incorrect in this assumption.

Anyways, what would be possible without changing or adding any existing modifier key logic would be to simply implement "Ctrl + zoom hotkey in/out = frame step +1/-1." I'm happy to add that. Most users are likely to leave zoom in/out linked to the mousewheel, and it seems a good idea to also be able to framestep like this by default.

A thought occurs though. Using the mousewheel to framestep is a good idea, but maybe the increments should be slightly larger than 1. I'd suggest somewhere between 5 and 10 as a good alternative. It makes movement forwards & backwards more what you'd expect from mousewheel use.

[Guigui]

I see the trouble coming from having the modifier keys used only for modifiers too. I think it'd break the habits of many player.
So yeah maybe the latter solution by WillLem where you set a default frameskip on CTRL+wheel up or down is the best.

Personnaly I'd prefer the frame skip to be +/1 frame on the CTRL+wheel, I like to have precise frame step at hand and can use the keyboard if I want faster skips. But while we're at it, why not :

* wheel only = zoom as usual
* CRTL+wheel = +/- 1 frame skip
* SHIFT+wheel = +/- 10 frames skip

[WillLem]

EDIT: Managed to get the behaviour hard-coded to the mousewheel after all; it was much simpler than I originally anticipated.

Linking the proposed behaviour to the zoom hotkeys as opposed to directly to the mousewheel handler is by far the easier approach to take here. It's a few lines of code and it works perfectly.

Attempting to hard-code it to the wheel would be a lot more of a bug-prone effort. The wheel can currently have any hotkey action linked to it, so we'd have to find a way to bypass that action (from a place of not necessarily knowing what the action is) as well as implementing the new framestepping behaviour and ensuring that other mousewheel event handling isn't affected. Not trivial, and tbh not worth the effort.

Let's add the framestepping behaviour as a modifier-accessible action of zoom in/out, then. I imagine that the vast majority of users keep zoom in/out linked to the mousewheel anyway. The framestepping, then, is a nice added bonus.

So, ensuring that zoom in/out remains linked to the mousewheel, we have:

Wheel only = zoom in/out
Ctrl+Wheel = step +1/-1
Shift+Wheel = step +10/-10
Alt+Wheel = step +100/-100

Let's give this a try in CE 1.1 and see what we think.

[Guigui]

Sounds great, thank you.

[Simon]

Oh, you're hardcoding. Then:

My hunch is to rewind with wheel-up + modifier keys, and to forward with wheel-down. Guigui recommends it the other way. And it sounds like WillLem has implemented it Guigui's way.

Reasons:

• Wheel-up moves back in a document. It should move back in time.
  
• Wheel-up zooms into details. It should move into history (= the details/reasons for the present).
  
• Wheel-up moves toward the top of a list. NL lists the earliest plies at the top of the replay editor. But it's not only NL: Lix lists the early plies at the top of the tweaker. And both NL's and Lix's replay files are sorted by in-game time, with early plies at the top.
  

Or, Guigui, do you have a specific reason why you want to rewind with wheel-down?

This feature has potential. Might warrant more love than hardcoding, but if we hardcode for the first release, we should think about direction.

-- Simon

[Guigui]

Good call Simon.

I think I just made a mistake in the OP. Trying to imagine it in action, I can definitely see wheel down for forward, and wheel up for backward.

[WillLem]

I disagree to be honest. Wheel up is a forwards motion, so it feels like that should also be "forwards in time", and vice versa. Probably best to implement both and make it optional, since everyone is likely to have a different preference.

For now, I've swapped the direction as Simon suggested, but I would like the option to have it the other way.

What are the alternatives to hardcoding? More menu options?


Meanwhile, whilst looking at this again, I've managed to get the framestepping behaviour hard-coded to the mousewheel itself (rather than the zoom in/out actions). It still relies on modifiers to work.

So, if Ctrl/Shift/Alt are pressed, we get +/- 1/10/100 framesteps, with the wheel determining the direction. If the modifiers are not pressed, the mousewheel performs its user-configured hotkey action (zoom in/out by default, but could be anything).

This is soft-implemented (in commit 9ef191c). I say "soft" because the thought occurs that, since we're also allowing modifier keys to be used as one-shot hotkeys, pressing the modifier to get the mousewheel framesteps also fires up whatever action is linked to Ctrl, Shift or Alt (depending on which modifier is pressed). This is obviously not ideal.

So, really, if a user wants the modifier + wheel behaviour, they need to not be using the modifier keys to perform any other action. I can't think of a sensible way around this.

[Simon]

I'm not sure either whether wheel-up or wheel-down is better for rewinding. Option is sensible.

I think it's correct to continue offering one-shot LCtrl, RCtrl, LShift, ... If it clashes with that rewind, so be it. I assume the wheel-rewind will eventually be optional altogether (not merely which direction, but whether the wheel rewinds at all).

No idea yet for how to reconcile the feature with the remaining hotkey mappings.

-- Simon