Events only fire for one button at a time

[cbrahe]

@kfl

Executing interact and holding down any button will repeatedly fire KeyPress events for that button. If a second button is pressed at the same time then KeyPress events for the second button will fire repeatedly, however KeyPress events for the first button will stop.

E.g. holding down first DownArrow then UpArrow at the same time will result in the following events firing:

...
DownArrow
DownArrow
DownArrow
DownArrow
DownArrow
UpArrow
UpArrow
UpArrow
UpArrow
UpArrow
...

When these events should supposedly be firing:

...
DownArrow
DownArrow
DownArrow
DownArrow
DownArrow
UpArrow
DownArrow
UpArrow
DownArrow
UpArrow
DownArrow
UpArrow
DownArrow
UpArrow
...

Demonstrative snippet:

#r "nuget:DIKU.Canvas, 2.0"
open Canvas
open Color

let tree = ellipse darkCyan 2.0 85.0 64.0 |> translate 128.0 128.0
let draw _ = make tree
let react _ e = printfn "%A" e; None
interact "Render an image" 256 256 (Some 1000) draw react 0

[kfl]

Hmm. I agree that something like the what you describe as expected behaviour is not unreasonable. However, I'm not convinced that the current behaviour isn't also reasonable.

diku-canvas is only doing the bare minimum wrt keyboard handling, so what you are seeing is the default behaviour from SDL and the keyboard configuration on your computer.

To keep things simple diku-canvas doesn't report multi-key combinations(*). The main reason is that it makes handling text input much harder. For instance, to enter an upper-case letter you need to hold down two keys (if we ignoring CAPS LOCK, but that's a whole new kettle of fish). This choice make certain game-like input harder.

All in all, diku-canvas isn't intended to be a library that caters for all kinds of usage. It is made for a specific purpose, and it tries to strike a balance between making many things possibly while staying simple and not burden the users with details that they might not be ready to be bothered with.

I'm not saying that we have hit the perfect balance, and I'm definitely open for suggestions and changes.

(*) To handle multi-key input would make the Canvas.Event type more complicated, and opens up questions such as what about holding down a key while using the mouse.

[cbrahe]

Could a solution be to add a KeyRelease case, containing a value for the released key, to the Canvas.Event type? This would seem one satisfactory way to preserve simplicity while extending the "game-like" functionality. Testing locally SDL seems to behave as required when firing KeyRelease.