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
At the moment we have a KeyboardShortcut interface that we use to store keyboard shortcut information.
This interface allows us to create shortcuts like
consttrueShortcut={description: "Add a 'true' decision for 'cow'",keys: [shiftSymbol,"q","o"]}satisfiesKeyboardShortcut;
However, this format is not really useful for keyboard event listeners which would need to listen for the "Q" keys being held down. Notice that "Q" is capitalized in the event listener because it requires shift.
This means that a lot of the time, our event listeners do not use this KeyboardShortcut interface e.g. the ClassificationComponent because it's easier to just use the raw key.
I think that not using the KeyboardShortcut interface is a smell that the interface is not expressive enough.
Therefore, I propose that the KeyboardShortcut interface should handle recognizing its own keyboard events. This would mean that all keyboard shortcut matching would be done in one place and not spread out over the entire client.
Having a single place for shortcut event matching would also make it easier to change the behavior of shortcuts and add functionality in the future.
E.g. Supporting keyboard patterns would be trivial with a KeyboardShortcut class (example of extending keyboard shortcuts; this is not something that I actually want to support)
consttrueShortcut=newKeyboardShortcut({description: "make a true decision",keys: [[CtrlSymbol,"K"],["O"]],});
In this example it would be verbally described as
"Hold ctrl and press 'K', lift up ctrl + 'K', then press 'O' to 'make a true decision'"
An Example of what the class might look like
exportclassKeyboardShortcut{publicconstructor(publickeys: ShortcutKey[],publicdescription?: string,publichasMouse=false)// probably not a static field. Maybe a service, but just for illustrative purposesprivatestaticpreviousKeys: string[]=[];publicisShortcut(event: KeyboardEvent){constrequiresShift=keys.some((key)=>key===shiftSymbol);consthasRequiredModifiers=requiredShift&&event.shift;constpreviousCombinations=KeyboardShortcut.previousKeys.slice(this.keys.length);returnpreviousCombinations.all((key,i)=>key===this.keys[i]);}}
The text was updated successfully, but these errors were encountered:
At the moment we have a
KeyboardShortcut
interface that we use to store keyboard shortcut information.This interface allows us to create shortcuts like
However, this format is not really useful for keyboard event listeners which would need to listen for the "Q" keys being held down. Notice that "Q" is capitalized in the event listener because it requires shift.
This means that a lot of the time, our event listeners do not use this
KeyboardShortcut
interface e.g. theClassificationComponent
because it's easier to just use the raw key.I think that not using the
KeyboardShortcut
interface is a smell that the interface is not expressive enough.Therefore, I propose that the
KeyboardShortcut
interface should handle recognizing its own keyboard events. This would mean that all keyboard shortcut matching would be done in one place and not spread out over the entire client.Having a single place for shortcut event matching would also make it easier to change the behavior of shortcuts and add functionality in the future.
E.g. Supporting keyboard patterns would be trivial with a
KeyboardShortcut
class (example of extending keyboard shortcuts; this is not something that I actually want to support)In this example it would be verbally described as
"Hold ctrl and press 'K', lift up ctrl + 'K', then press 'O' to 'make a true decision'"
An Example of what the class might look like
The text was updated successfully, but these errors were encountered: