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

All I remember is that it was fairly easy to fix this in fltk2.0. The bogus key-up/down messages are sent as the same block of events. So when the key-up message is received, the key-down is a pending event, immediately available and already in the Xlib incoming event buffer. There absolutely should be no need for a timeout.

Relevant code from fltk2.0 handlng of KeyRelease events:

// Bogus KeyUp events are generated by repeated KeyDown events. One
// neccessary condition is an identical key event pending right after
// the bogus KeyUp.
// The new code introduced Dec 2009 differs in that it only check the very
// next event in the queue, not the entire queue of events.
// This function wrongly detects a repeat key if a software keyboard
// sends a burst of events containing two consecutive equal keys. However,
// in every non-gaming situation, this is no problem because both KeyPress
// events will cause the expected behavior.
XEvent peekevent;
if (XPending(xdisplay)) {
XPeekEvent(xdisplay, &peekevent);
if ( (peekevent.type == KeyPress) // must be a KeyPress event
&& (peekevent.xkey.keycode == xevent.xkey.keycode) // must be the same key
&& (peekevent.xkey.time == xevent.xkey.time) // must be sent at the exact same time
) {
XNextEvent(xdisplay, &xevent);
goto KEYPRESS;
}
}

On Fri, Sep 24, 2021 at 8:53 AM rs <rspinney20@gmail.com> wrote:

Ok, So I'm using PopOS 20.04 LTS with Mate desktop environment and Metacity (Marco) as the window manager (thats the output of wmctrl -m)

The output of cat /proc/version is

Linux version 5.11.0-7620-generic (buildd@lgw01-amd64-045) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #21~1626191760~20.04~55de9c3-Ubuntu SMP Wed Jul 21 20:31:55 UTC

@Albrecht

I ran your version and it runs into the same issue. Here are some sample outputs:

A longer one:

1 - toggle_win, shown() = 0
1 - FL_ALT is on , key = 's', shown = 1
2 - toggle_win, shown() = 0
2 - FL_ALT is on , key = 's', shown = 1
3 - toggle_win, shown() = 0
3 - FL_ALT is on , key = 's', shown = 1
4 - toggle_win, shown() = 0
4 - FL_ALT is on , key = 's', shown = 1
5 - toggle_win, shown() = 0
5 - FL_ALT is on , key = 's', shown = 1
6 - toggle_win, shown() = 0
6 - FL_ALT is on , key = 's', shown = 1
7 - toggle_win, shown() = 0
8 - toggle_win, shown() = 1
9 - toggle_win, shown() = 0
<--- fails here

A short one:

1 - toggle_win, shown() = 0
1 - FL_ALT is on , key = 's', shown = 1
2 - toggle_win, shown() = 0
3 - toggle_win, shown() = 1
4 - toggle_win, shown() = 0
<--- fails here

>As you can clearly see 'toggle_win' (the menu callback) runs much more
often than the event handling of the derived window class, which is to
be expected because of the X server turnaround needed to effectively
show/hide the window.

So I see this too, but it is what (appears to be) causing (or at least coinciding) with the problem. Note that when the output stops (because the keyboard input stops/breaks) the second window is always *shown* on the screen.

Thanks,

R.
On Friday, September 24, 2021 at 10:51:34 PM UTC+10 Albrecht Schlosser wrote:

On 9/24/21 2:37 PM Ian MacArthur wrote:

On Friday, 24 September 2021 at 13:29:23 UTC+1 Albrecht Schlosser wrote:

I'm late to the party, but anyway... I tried the original test program
on my Linux Mint 20 system and didn't see any issues. It seems to toggle
the 2nd window as expected.

Hi Albrecht,

The behaviour is (at least rumoured to be) dependent on which specific X11 setup is used, and may vary from host to host, so it's quite likely that the same program will behave differently depending on which X / WM / whatever, is in use.

Hi Ian,

that's why I reported my results and asked the OP to try my test program on their system and report their results. Maybe this can give us a clue what's happening on that system. Which reminds me that I forgot to ask:

@OP: which Linux flavor and version and which WM are you using?

Which is a nuisance to work with...

I agree.

--
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/2425c9c4-710a-44db-b0ed-ed0749e79040n%40googlegroups.com.