You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seeing as you're active on this module again, was wondering would there be any interest in integrating the enhancements from my fork? Specifically:
Events: up/down event emitters for each keybinding, behaving similarly to keyup/keydown DOM events except without automatic repeat. Mainly it is useful to have these events here so keybindings can be centrally managed in one location.
Without these event emitters, one has to listen for the DOM events instead. But then the listeners not necessarily enabled/disabled when kb-controls is enabled/disabled.
Routing all keyboard interaction (both polling and events) through the same handler solves the problem where, for example, you want to accept arbitrary keyboard input in a text box by disabling normal game controls, but because other code has directly attached its own DOM listeners their keybindings are unintentionally triggered - https://github.com/deathcap/voxel-modal solves this by calling this.game.interact.release(); which in voxel-engine Game.prototype.onControlChange calls this.buttons.disable() in this module. Polled keys are correctly handled in this case but evented keys (such as "R" commonly used to change point of view in voxel.js apps) "leak" through without some kind of centralized keybinding control. Also centralized keybinding control has another benefit:
Reconfigurable keybindings: exposing the bindings structure so it can be changed dynamically at runtime. This is especially useful for allowing end-user configurable keybindings as common in games, example using dat.gui: https://github.com/deathcap/kb-bindings-ui . Since all the keyboard shortcuts are handled in one place, this list is comprehensive - interactive example at http://deathcap.github.io/kb-bindings-ui/ :
Let me know if you want a PR for these changes, would be happy to deprecate kb-bindings in favor of kb-controls (didn't think they would be considered within the scope of kb-controls - based on the discussion in #1 with @maxogden though I can only see half(?), so I forked kb-bindings with the goal of more comprehensive keybinding handling for my purposes). Or if you have ideas for cleaner alternative techniques. cheers
The text was updated successfully, but these errors were encountered:
Seeing as you're active on this module again, was wondering would there be any interest in integrating the enhancements from my fork? Specifically:
Events: up/down event emitters for each keybinding, behaving similarly to keyup/keydown DOM events except without automatic repeat. Mainly it is useful to have these events here so keybindings can be centrally managed in one location.
Without these event emitters, one has to listen for the DOM events instead. But then the listeners not necessarily enabled/disabled when kb-controls is enabled/disabled.
Routing all keyboard interaction (both polling and events) through the same handler solves the problem where, for example, you want to accept arbitrary keyboard input in a text box by disabling normal game controls, but because other code has directly attached its own DOM listeners their keybindings are unintentionally triggered - https://github.com/deathcap/voxel-modal solves this by calling
this.game.interact.release();
which in voxel-engineGame.prototype.onControlChange
callsthis.buttons.disable()
in this module. Polled keys are correctly handled in this case but evented keys (such as "R" commonly used to change point of view in voxel.js apps) "leak" through without some kind of centralized keybinding control. Also centralized keybinding control has another benefit:Reconfigurable keybindings: exposing the
bindings
structure so it can be changed dynamically at runtime. This is especially useful for allowing end-user configurable keybindings as common in games, example using dat.gui: https://github.com/deathcap/kb-bindings-ui . Since all the keyboard shortcuts are handled in one place, this list is comprehensive - interactive example at http://deathcap.github.io/kb-bindings-ui/ :Here's my fork if you are interested: https://github.com/deathcap/kb-bindings (also using a branch of voxel-engine which can be told to use either kb-controls or kb-bindings: deathcap/voxel-engine@61177bd, not sure this is the best way to do it though)
Let me know if you want a PR for these changes, would be happy to deprecate kb-bindings in favor of kb-controls (didn't think they would be considered within the scope of kb-controls - based on the discussion in #1 with @maxogden though I can only see half(?), so I forked kb-bindings with the goal of more comprehensive keybinding handling for my purposes). Or if you have ideas for cleaner alternative techniques. cheers
The text was updated successfully, but these errors were encountered: