Hello! I believe I may have run into a glib or gtk bug that was ported from gtk2. I could use some help determining how to debug / gather more information / work around this issue.
On rare occasions, while in a dialog, all signals and events are not received for touch or click events -- however, after a keyboard event comes in, the click events (that appear to have been queued) are now received. More info: ubuntu 18.04 server glib: 2.56.3-0ubuntu0.18.04.1 gtk: 3.22.30-1ubuntu1 I have a piece of code that calls: gtk_dialog_run() and displays a dialog that has text but no button. After a "background" task completes: (called by gdk_threads_add_timeout_full( G_PRIORITY_DEFAULT_IDLE, 10, TimerCallback, 0, NULL );) the dialog is updated to add an OK button to continue. Most of the time (perhaps 49/50 times) the OK button receives signals as expected; however, 1/50 times, no signals/events attached to that button are received. Notes: 1. To the user, the screen appears unresponsive. Taps (on the touchscreen) or clicks (with an attached mouse) anywhere on the screen have no effect. 2. I have confirmed (with GDB and with prints in the TimerCallback noted above) that the g_main_loop_run() is continuing to run freely (no deadlocks). 3. It is possible that this error is more reproducible if the user taps more than once on the button that triggers the dialog to be created, but this is not confirmed. 4. For debug purposes, I have attached to the "event" signal, as well as the "button_press_event" and the "clicked" event of the "OK" button -- no events of any kind are received when in this state. 5. I confirmed that the touch screen is actively sending data (cat /dev/input/event5 shows the expected binary output) 6. Once in this state, click events with a mouse are also not received (so this does not appear to be related to the touch screen, except perhaps for (3) being easier to reproduce by tapping). 7. If, after tapping "OK" in this state (and nothing happens), the user then types any key on the attached keyboard, the touch (or mouse click) events are now received by the button, and the program continues as normal. Questions / Thoughts: 1. Does anything come to mind which could cause touch / click events to be queued and not sent to the gtk widget until a keyboard event comes in? 2. Is it possible that, for some reason, an extra click is causing the focus to not be on the dialog? But, if so... why would touch events be queued and then released when a keyboard event comes in? 3. Any suggestions to gather additional debug info? Is there a good way to monitor if the touch and click events are being received by GLib? Where is the X-input processing queue? Any suggestions on source code to read? 4. Any suggestions for a workaround? (Ideally not something like "send keyboard events periodically" ;-) Many Thanks, Eric
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
