recursion / hotkeycommander Goto Github PK

So much tidying up needed. Not sure where to start.

Currently this is using pure javascript to handle template loading and view rendering.

The template loading is done using the import statement, which is only really supported in chrome. Simple, nice. Not portable.

We need to select a template/render process that has more broad browser support, ideally something flexible enough to let the module user decide how he wants to render the views / load the templates himself?

As a user id like to be able to use alt, ctrl, and shift.

The engine and data model is currently constructed in such a way that this should be something we can implement without 'too' much work.

Would be nice to use something like jsdoc to get some decent documentation.

Currently the on/off toggle will always be displayed to the user, where some applications may not desire that.

The developer should be able to pass in a config option that determines whether or not the on/off toggle is displayed.

As a user I want a notification of some sort when I am unable to record a key for some reason. For instance: when a key is already in use.

Currently the engine is monitoring keydown events. That means we would respond to every keyboard events - of which keydown repeats every X microseconds the key is held down.
This could be desirable. Or not.

Others may prefer to make sure one event fires for 1 keypress - and that a user should have to release the key, and press again for a new event.

This is a design decision that needs to be made. Ideally the developer could configure that option at start time as he needed.

It would be nice to at least test the entire packages ability to take an object of hotkey definitions along with a properly mapped 'commander' object - and verify that its making the proper calls when it should.

So last time I was toying around with hkc, I noticed some breakage in certain browsers.

It seems that .keyCode has been deprecated and .key is now used.

This is actually better overall, but will require a few changes to the codebase. It looked like printing .key directly to screen/html may have some issues (unicode?) when I tested it out, so they may be the only hangup.

Engine, configurator, and the view will all have to be updated/changed. Also we should no longer need to use the keycode 'localization' map/file.

I might not always want to use hotkeys. And so being able to turn them on and off (perhaps with a hotkey) would be a great feature to have.

A user might want to reset to default settings.

The module should produce readable errors for any developers trying to use it.

Assigning a key to a function where the key is already in use by another function ends with both keys being added, but only the newest will actually be used.

• In the instance where a user tries to assign a key that is already in use, there needs to be some sort of response.
  • It could be flat out rejected. 'CANNOT USE KEY IN USE'
  • It could swap the existing key with the one being changed - so that keys stay unique.
  • We could alert the user and let them choose either option.

Wording could use improvements across the board so that setup/usage is easier to follow/understand.

Currently the package is using babel-presets, which loads everything. Most of which is not needed. The package could be significantly slimmed down by removing the 'babel-presets' tag, and loading on the needed babel components.

The css should not need to be included in projects using hotkey-commander. It should just be included with the bundle.

• Loading: At startup the app should check a storage location for existing user hotkey settings, if not found, it should load defaults.
• Saving: Since we cant always know when shutdown is (can we?) - we should probably always hit the persistent storage when a key is changed/updated.

Currently a developer wanting to use the package would need to create a hotkey definition list by hand, looking up ascii keyCodes the whole way. Yuck.

A developer should be able to quickly and easily create hotkey definition lists and add new hotkey definitions.

A CLI node app would be great for this.

This way when a new user is getting familiar with the app - they can see what their hotkeys would be doing if they were 'active' - but since the user is in test mode - orders dont go live - they just pop up an alert with data for the user. (this would be nice for testing too eh...)

Extended keyCode keys, like: + / \ ' (with key codes above 127) - do not display the same way the characters below that range do.

This is most likely something simple related to:

• event.keyCode returns extended codes for these keys,
• String.fromCharCode is the function being used to generate a character.

It would be nice to have logging throughout the application - that can be turned on/off from a single place. A logger object would be great for this. Custom or imported