Glade Panel in Axis blocks arrow keys

Here is the single file attached.

Thanks for the feedback, for now I'm back to using the good old stable pyvcp sidepanel, as using the gladepanel productively was too dangerous for me. If someone comes up with a solution in the future I'm still interested.

Best wishes

Jan

I have the same issue for glade tabs.
I'm on 2.9, and whenever i jog and move the mouse pointer into a tab, the jog continues after releasing the jog button.

I'm a quite experienced programmer, but it seems difficult to get key forwarding working.
Does anyone have an idea on how to approach this issue in a way that will work?

Hello everyone,

after all these years, I finally seem to have found a solution to the problem described in this thread.

I should mention that I'm not really a programmer, so I investigated this with quite a bit of help from AI. Essentially, an amateur debugging LinuxCNC with AI assistance.

The original problem was that when jogging an axis using the arrow keys in AXIS, moving the mouse pointer into an embedded GladeVCP panel and releasing the key could cause the axis to continue moving.

I reproduced the issue in an isolated LinuxCNC 2.9.10 simulation and added some debugging output to AXIS and GladeVCP.It turned out that GladeVCP correctly receives the KeyRelease event, but the forwarded event does not always reach AXIS.

The solution appears to be surprisingly simple:

In lib/python/gladevcp/xembed.py, inside keyboard_forward()

add d.flush() immediately after fw.send_event(fe):


fw.send_event(fe) d.flush()


I performed an A/B/A test:

- With d.flush(): Jogging stops correctly.
- Without d.flush(): The original problem returns.
- With d.flush() restored: Jogging stops correctly again.

I also restored the original LinuxCNC 2.9.10 xembed.py and applied only this single-line modification. The fix still works.I tested repeated jogging and switching between axes, releasing the arrow keys while the mouse pointer was inside the GladeVCP panel. So far, the problem has not reappeared.

Please note: All testing was done in a simulation, not on a real machine. This is not a safety validation.Since I can`t guarantee that this is the correct upstream solution, it would be great if someone familiar with the XEmbed implementation could review the change.Maybe this little fix can finally put an end to an issue that has been around for quite a few years!

I attached the modyfied xembed.py file.

Best regards,

Jan