In contemplating the issue of having connect(self, doKeyCommand, self, Input.keyCommand) in either the draw or initialize slot, as well as allowing for user override, I ask Gemini for some suggestions. The one that stood out for me is the idea of doBeforeKeyCommand and doAfterKeyCommand signals, allowing for either overriding or extension. It also eliminates connect(self, doKeyCommand, self, Input.keyCommand) if we move the keyCommand code directly into keyPress.
input.nim
proc doBeforeKeyCommand*(self: Input, pressed: set[UiKey], down: set[UiKey], var handled: bool) {.signal.}
proc doAfterKeyCommand*(self: Input, pressed: set[UiKey], down: set[UiKey]) {.signal.}
proc keyPress*(self: Input, pressed: set[UiKey], down: set[UiKey]) {.slot.} =
var eventHandled = false
emit self.doBeforeKeyCommand(pressed, down, eventHandled) # Pass 'handled' by var
if not eventHandled:
# Execute default internal key command logic here directly
emit self.doAfterKeyCommand(pressed, down) # For post-processing
tinput.nim
Input.new "myInput":
let myInputWidget = this
connect(myInputWidget, doBeforeKeyCommand) do (mainApp: Main, p: set[UiKey], d: set[UiKey], handled: var bool):
if UiKey.KeyX in p and d.matches({KControl}): # Ctrl+X
echo "tinput.nim: Ctrl+X intercepted by doBeforeKeyCommand!"
# Perform custom cut operation
handled = true # Signal that we've handled it; default logic won't run
In contemplating the issue of having
connect(self, doKeyCommand, self, Input.keyCommand)in either the draw or initialize slot, as well as allowing for user override, I ask Gemini for some suggestions. The one that stood out for me is the idea ofdoBeforeKeyCommandanddoAfterKeyCommandsignals, allowing for either overriding or extension. It also eliminatesconnect(self, doKeyCommand, self, Input.keyCommand)if we move the keyCommand code directly into keyPress.input.nim
tinput.nim