Keybinding window support for mouse bindings

[Knight-Ops]

I don't believe there is any reason that the Keybinding window should only support keyboard presses. I suspect it is an oversight here : https://github.com/blish-hud/Blish-HUD/blob/73863ba1993bb2c4b3a5d8b4ab8263dcdc0ed901/Blish%20HUD/Controls/KeybindingAssignmentWindow.cs#L90

Where only the Keyboard state change callback is being added.

C# is far from my best language or I would submit a pull instead of an issue.

This would allow for various keybindings in BlishHUD to be bound to a mouse key without the need for mouse keys to be bound/macro'd to keyboard presses.

[dlamkins]

This is already something that's been in heavy discussion recently. It's not currently implemented because it's far more complicated than that.

• Keybindings themselves need a way of containing this information. Likely a new property.
• Our keybinding triggering is based on the KeyboardHandler. It would need to be extended to include the MouseHandler.
• The KeyboardHandler and MouseHandler both handle input blocking which would need to be extended to the MouseHandler for keybindings that are configured to block the input to the game (which we must be careful due to the amount of load on the mouse hook to ensure we don't slow things down for them).

Until we get this implemented, users can use one of the following workarounds.

1. Changing your mouse buttons binding to be that of a normal keyboard key (such as one of the late F keys like F13+ and binding your actions to that).

2. If it's a mouse key that also has utility (like forward / back mouse keys) that you're binding, if you have assignment options for your mouse, you can assign two actions to the single button press -> The first action would be the original mouse key (like forward or back) and the second action would be a keypress such as one of the later F keys. This would allow you to retain the functionality of the mouse key while also having a key that you can bind against.

An example of option 2 (which has far fewer compromises) in Logitech's software can be seen in this GIF: https://gfycat.com/bronzebeneficialafricanelephant

[dlamkins]

Keeping a checklist here of what will be needed to add support for this that I'll update as we make progress or encounter further things in the way.

• [ ] MouseHandler needs support for reporting XButton1 and XButton2. We currently drop these.
  • [ ] MouseEventType enum needs updated.
  • Reference information: WM_XBUTTONDOWN / WM_XBUTTONUP - parameters indicate which of the two buttons it.
• [ ] Keybindings need support for including mouse buttons (primarily 3 - 5 so middle-mouse and button 4 and 5).
  • [ ] This will likely need to be a third property using a new enum since Xna.Input doesn't appear to have one already for mouse buttons.
  • [ ] Logic for splitting keybinds will need to be updated in the keybinding util.
• [ ] Keybinding control needs to begin listening for mouse key events to allow for assignments.
  • Logic needs updated here to ensure it's either a key based binding or a mouse button binding in addition to the modifier (not both).
• [ ] MouseHandler needs to be able to trigger keybinds like KeyboardHandler.
  • Since MouseHandler is always the second half, it likely doesn't need support for staging them. Only firing them if staged by a modifier.

[Knight-Ops]

Thanks for outlining what is required. I only did a cursory glance at the code so I am glad you cleared that up.

RE: Suggestion 2, you may want to be careful here, that suggestion actually violates the terms of service for GW2 where as 1 mouse-press results in multiple keys (Its a macro through Logitech) I doubt Anet would care realistically, but its a line to be careful of.

[dlamkins]

RE: Suggestion 2, you may want to be careful here, that suggestion actually violates the terms of service for GW2 where as 1 mouse-press results in multiple keys (Its a macro through Logitech) I doubt Anet would care realistically, but its a line to be careful of.

Just to clarify, that is incorrect. You're referring to the Macros and Macro Use and the Dual or Multi-Boxing policies which state (in order):

Each macro should represent a single action that requires user input before repeating the action.

and

One keystroke should translate to one action on one account.

The policy is not specifically referring to key or button presses needing to be singular. It is the resulting actions that must be singular.

The first policy also states:

Attended macro use is permitted as long as it is not exploitative, and as long as it does not provide the user with an unfair advantage over other players.

And most importantly: a reminder that the macros we're discussing here aren't for Guild Wars 2. They're for Blish HUD. You're creating a macro so that Blish HUD can properly accept your input. Gotta keep the divide between what input we're receiving and what input is being sent since they are different scenarios.

Wanted to make sure I lay this all out in case there was anyone with any concerns about ToS for the above workarounds.