FLTK logo

Re: [fltk.general] Re: Losing keyboard input under user 'spamming' input

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: Losing keyboard input under user 'spamming' input Bill Spitzak Sep 23, 2021  
 
I believe this is some stupidity by the X11 developers, instead of making keys repeat as they used to, X reports many key down/up pairs. There is a workaround added, I believe, to the fltk2.0 code, this needs to be copied into fltk1. Basically in the event handling when it gets a key-up, it needs to check if there is a key-down for the same key queued and instead turn it into only a repeating key-down event.

On Thu, Sep 23, 2021 at 10:14 AM rs <rspinney20@gmail.com> wrote:
>If it is a "feature" of the X11 client/server mechanism, it may be hard to dodge.

Yeah more and more this is what it looks like.

Might be able to start a fl_timeout on key_up events and then only toggle the show/hide state if the key_up is not followed by a key_down within the timeout period... or something. (I'm just making this up as I go along now, can you tell?)

Heh, yeah, perhaps. I think I'll go with my "disable on linux" approach...

However, the plot thickens... I thought about just slowing it all down so put some

std::this_thread::sleep_for (std::chrono::milliseconds(1000));

after  (and also before, with no difference) all show() and hide() calls as just a bodge, and it actually made things *worse* - it survived at most *one* single alt+s event (i.e. failing to perform the second) -  not event holding it down/spamming. Which is really weird (unless those timing calls are really messing up FLTK internals). That makes it seem like some kind of timing mismatch between showing the window and the handle/callback wrapping up... but I don't know enough about the internals.

I may give up here to be honest!
On Friday, September 24, 2021 at 2:20:27 AM UTC+10 Ian MacArthur wrote:
On Thursday, 23 September 2021 at 17:02:17 UTC+1 rs wrote:
It's a nice idea, but I tested it and, whilst it sometime "survives" longer (sometimes it doesn't - indeed sometimes only managing one full "loop" see below) whilst flicking the window on/off, it does eventually lead to the same problem. Basically, its not *just* FL_KEYBOARD events but also FL_KEYUP events that are continuously being generated, so this doesn't sidestep the issue. In an attempt a debugging with std::couts in a few places I get the following:

Ah... hmm, OK, that's a bit more of a nuisance...

FWIW, under Windows  (Win10, I only have my laptop today...) "my" version does not flicker at all, the win2 toggles on/off once per keyboard press, regardless how long I keep the "Alt+s" combo held for, suggesting (to me, at least) that the Win32 system is only delivering the KEY_UP when I actually let go the keys.

It's been a long time since I looked at raw X11 keyboard handling, so I can't remember what I'd even expect it to do, but it does look very much as if it is generating down/up pairs all the time when the key-combo is held down (where I think Win32 is generating streams of key_down events, but apparently fewer, or only one, key_up.)

(Actually, reading that back, that rang a very faint bell... there is something about handling repeat keys under X11, might be that fltk is generating synthetic events for repeated keys... but I can't remember any of the details...)

If it is a "feature" of the X11 client/server mechanism, it may be hard to dodge. Might be able to start a fl_timeout on key_up events and then only toggle the show/hide state if the key_up is not followed by a key_down within the timeout period... or something. (I'm just making this up as I go along now, can you tell?)

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/8de25866-c9f8-4e48-b8c3-317c058c5d65n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAL-8oAgU_-F8SSy_TumxaRE-yM0MZgR-HPD4-hPt7_%3DyPvpseA%40mail.gmail.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.