[FEAT] Keybindings for DM tools

[chisaipete]

Is your feature request related to a problem? Please describe. When drawing, it's tedious to constantly move back and forth between the toolbar to move from select to draw, back to select, and then draw tool again.

Describe the solution you'd like Simple keybinding defaults and options (perhaps paired with #130 ) for tools. Perhaps:

• Select = 1 or q
• Pan = 2 or w
• Draw = 3 or e
• Ruler = 4 or r

Describe alternatives you've considered This is a little hard to suggest without complete documentation on current keybindings. Maybe we need to get the docs updated first? 😁

Additional context None.

[Kruptein]

This would be an easy thing to implement. I just need to think about which keybindings I want to settle on.

[chisaipete]

After looking through the client code, it appears it would be good to add an abstraction player to enable customization of the keybindings in the client. Or do you feel that is out of scope?

[dthv]

I'd love to see some keybindings on the (great!) rotation within the select tool.

E.g.

• r = clockwise rotation (90°, 30°, or 15°; 15° preferred)
• shift + r = same as r, but counter-clockwise
• shift + mousewheel-up (while shape selected) = clockwise rotation (1°, 10°, or 15°)
• shift + mousewheel-down (while shape selected) = opposite of -up, of course :wink:

The mousewheel-events are accompanied by the Shift-modifiere to avoid collision with the zoom tool.

Another possibility for the Shift modifier would be to have 'normal' mousewheel-events to have 15/30/90 degree (30° preferred?) and use the modifiere for 'finetuning' with 1° or 10°. Ctrl / Alt should probably not used, as they tend to be used by the browser and/or system to zoom. Thus, in this case, mousewheel-zoom would no longer be useable when there's something selected (which might be not the best, actually).

[dthv]

Just some further musings: simply numbering the toolbar seems problematic to me as (1) the toolbar changes depending on the modes and (2) the toolbar changes depending on whether there are things to filter or check vision. This would either mean a constant change of 'addresses' or a toolbar where tool number 3 is adjacent to tool number 5. The same holds true for simply using a keyboard row left to right.

Thus, imo, contextual keybindings should be used. However, these come with their own problems, as e.g. d (which would be a natural binding for the drawing tool) already has a special meaning in the context of the select tool and is, thus, not apt for changing in between of the tools. p would raise conflict of priority in between the Pan an Ping tools; r probably between the Ruler tool and the rotation functionality of the Select tool (if my abovementioned request is implemented).

Even if all those keys will be editable in the client preferences, it will be hard to decide on the defaults.