Modifier key after clicking mouse - right design choice?



  • And finally this, a long term observation.

    I wonder a bit about this design decision. I am used from other programs to pressing the modifier key first then cliking and moving the mouse, for example SHIFT then pull handle. That way nothing is moved before I with the modifier tell the program to keep the angle as it were.

    In VS it is the other way around? Click and pull first then hit SHIFT or whatever. That way I start to pull slightly wrong (wrong angle) then right angle when the modifier is pressed. Alternative is to click and not move the mouse sitting still like a duck during hunting season, then press SHIFT. 🙂

    Pressing SHIFT first locks the node or handle firmly in place; does nothing when you try clicking and moving the mouse.

    If there is any way around this implementation in the architechture of VS I strongly recommand allowing pressing the modifier key FIRST as well. Just to clarify: pressing modificer before or after the mouse button should result in the same behavior from VS. Like in other programs. 🙂

    I cannot think of any clash with features or workflows in VS. But it does indeed clash with habbits and muscle memory.


  • administrators

    @Ingolf In some cases, pressing modifier first and then moving the mouse would be possible. I think a case-by-case fix for this can be made.

    But: there are several cases, pressing the modifier first will result in a different series of actions, than pressing it after the mouse is held.

    The most notable case of this is the use of the Command+ (Mac) (Control on Windows) key: pressing the Command first will activate the alternate editor (for ex: Node editor), but pressing the Command after the mouse movement is started, will disable snapping, while staying in the Transform.

    Unfortunately, there are not enough modifier keys for all the possible options, so the occasional before / after mouse press differentiation is one way to make room for more.

    But of course, staying consistent with existing workflows, must be considered when possible.



  • @vectoradmin

    Ah, got it, so it is a bit complex 🙂

    I'll probably get used to it but in those instances where holding the modificer is not in conflict with any other key combo but kind of blocks further action with the mouse it would be beneficial to allow the modificer to be pressed first instead.


  • administrators

    @Ingolf If there are cases that do not make sense, please report it!