On Thursday, 23 September 2021 at 15:20:24 UTC+1 rs wrote:
Under sensible user input and on certain OS's this all works fine. However on Linux, and unlike on Mac (I haven't checked Windows yet), holding buttons down seems to generate multiple key FL_KEYBOARD events (as opposed to just a single one when it is depressed/released).
FWIW, tried your example on Win10, seems fine - in that win2 was repeatedly shown then hidden, and continued to flicker on and off continuously until I got bored...
Not sure if that's what macOS does for you, but it didn't crash, in any case.
I suspect X11 versions might need a client->server round trip for the window events, so may well be substantially slower than macOS or Win32.
As such the user can simply hold Alt + S, effectively spamming the shortcut. After, say, a second of this something breaks and the whole FLTK program simply doesn't appear to receive keyboard events anymore (other events like mouse presses are fine). I thought it might have been that focus got "lost" somewhere and so tried refocusing on the main window, but this didn't work.
I have other instances where holding down a button can be dealt with just fine (where it is just updating some data, not hiding/showing/setting FLTK objects), so it is something to do with the hiding and showing of the window - maybe some increasing queue of window hide/show calls are overflowing some buffer due to them accumulating faster than the OS can actually hide and show them, I don't know.
No good idea now - there are a few places in fltk where we queue events, but the queues are (IIRC) mostly pretty deep (thousands) and in any case I think they are protected against overflow... But you never know.
I suppose it might be event queues in X11 too, though I'd expect that to be able to handle key-repeat events without failing, so that seems unlikely too.
