You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using VSG master, updated today, on Kubuntu 24.04.
I've been losing control of ImGui sliders and have tracked the problem down to 'sticky' modkeys. I can also see the sticky modkeys using the ImGui demo window Tools->Metrics/Debugger->Inputs.
The simplest test is to run vsgimgui_example, open the demo window then Tools->Metrics/Debugger->Inputs. Press Left_CTRL and observe the Keys Down line. Both LeftCtrl and ModCtrl are displayed, but when you release the key only the LeftCtrl disppears and ModCtrl remains.
This can be traced back to SendEventsToImGui::_updateModifier(ImGuiIO& io, vsg::KeyModifier& modifier, bool pressed).
When you press Ctrl the modifier bit field has the MODKEY_Control bit set (4) and pressed is set to true. This looks to work as intended. However, when you release the Ctrl key there are no bits set (MODKEY_OFF) and pressed is set to false, but the bit comparison doesn't pass, so the modifier key in ImGui doesn't not get reset to false. Therefore, the Ctrl keys appears stuck on in ImGui.
Testing by combining multiple modkeys (eg Shift & Ctrl) and releasing one at a time shows that _updateModifier() is being sent the current modkey bitfield rather than the changes to the bitfield in Linux. This also has the result of sometimes turning off the incorrect modkey eg: Press both Shift and Ctrl (both set correctly in ImGui), then release Shift key so that the only bit set in modkey is for the Ctrl key, but pressed is now false, so Ctrl is toggled off and Shift left on in ImGui.
This issue doesn't appear to affect Windows.
This could be fixed on Linux by updating all modkeys according to their bit in modifier every time the method is called (and ignoring the pressed variable), or perhaps by caching the modkey state and updating any bits that have changed. However, this would appear to be different logic to the way the Windows implementation works.
Is it simpler to make Linux modkey handling the same as Windows? I'm not familiar with how the key event is set on various platforms before being sent to the event handlers.
Regards,
Roland
The text was updated successfully, but these errors were encountered:
Hi Robert,
I'm using VSG master, updated today, on Kubuntu 24.04.
I've been losing control of ImGui sliders and have tracked the problem down to 'sticky' modkeys. I can also see the sticky modkeys using the ImGui demo window Tools->Metrics/Debugger->Inputs.
The simplest test is to run vsgimgui_example, open the demo window then Tools->Metrics/Debugger->Inputs. Press Left_CTRL and observe the Keys Down line. Both LeftCtrl and ModCtrl are displayed, but when you release the key only the LeftCtrl disppears and ModCtrl remains.
This can be traced back to SendEventsToImGui::_updateModifier(ImGuiIO& io, vsg::KeyModifier& modifier, bool pressed).
When you press Ctrl the modifier bit field has the MODKEY_Control bit set (4) and pressed is set to true. This looks to work as intended. However, when you release the Ctrl key there are no bits set (MODKEY_OFF) and pressed is set to false, but the bit comparison doesn't pass, so the modifier key in ImGui doesn't not get reset to false. Therefore, the Ctrl keys appears stuck on in ImGui.
Testing by combining multiple modkeys (eg Shift & Ctrl) and releasing one at a time shows that _updateModifier() is being sent the current modkey bitfield rather than the changes to the bitfield in Linux. This also has the result of sometimes turning off the incorrect modkey eg: Press both Shift and Ctrl (both set correctly in ImGui), then release Shift key so that the only bit set in modkey is for the Ctrl key, but pressed is now false, so Ctrl is toggled off and Shift left on in ImGui.
This issue doesn't appear to affect Windows.
This could be fixed on Linux by updating all modkeys according to their bit in modifier every time the method is called (and ignoring the pressed variable), or perhaps by caching the modkey state and updating any bits that have changed. However, this would appear to be different logic to the way the Windows implementation works.
Is it simpler to make Linux modkey handling the same as Windows? I'm not familiar with how the key event is set on various platforms before being sent to the event handlers.
Regards,
Roland
The text was updated successfully, but these errors were encountered: