Onboard does not visually reflect modifiers activated via xte

Right, only Caps lock and Num lock are updated. I initially had all modifier changes reflected in Onboard, but that seemed too distracting when working with a physical keyboard in parallel, in particular due to constant flickering of the Shift keys.
These modifiers are used only transiently anyway and wouldn't hurt to not be updated, or so I thought...

Can you give some more details about what are you trying to do? What's your reason for keeping Shift down for longer stretches?

"Can you give some more details about what are you trying to do? What's your reason for keeping Shift down for longer stretches?"

In my case, I'm using xbindkeys and xte/xdotools to map certain window management functions to my Logitech Performance MX mouse. Specifically, I've mapped Shift_L to one of it's thumb buttons such that I can use the scroll wheel to zoom in and out (the relavent Compiz shortcut being Shift+Button 4/5). Ideally, I would have liked to have set xbindkeys such that holding the aforementioned zoom/thumb button would emulate holding Shift (i.e. I'd have to hold the zoom/thumb button whilst scrolling), but my efforts in this bore no fruit and I was forced instead to map the thumb button as a toggle for Shift_L.

Under these circumstances, it'd be nice to know whether or not I've accidentally left Shift_L toggled on. Regardless, it seems only right that a modifiers state be accurately reflected within Onboards UI, especially if it isn't transient.

"…in particular due to constant flickering of the Shift keys."

Hmm, quite understandable that you would move to quell this then. Here's a though, could you place a time condition on representing a modifiers active state, so as to exlude transient modiefiers (e.g. if Shift_L is active for ≥ x milli-seconds then display as active)? It might be a bit of a task to determine an appropriate setting for x, but I'm sure it could be done.

Regards,

Lee.

Yes, maybe a delay. Or Onboard auto-hides when typing with physical keyboards. Or both. Total coincidence, but that hiding is what I'm currently working on. There's a possibility that your mouse Shift press would cause it to hide too (if it doesn't go through the XTest device) so you won't see the shift keys, but you would be able to turn hiding off in preferences.

One more thing, no matter if Shift_L or Shift_R was pressed, you'd always get all shift keys highlighted in Onboard. The X modifier state we get has only this one Shift bit, unfortunately.

That's a nifty little feature for sure (autohide)! Although I am glad that there will be an option to switch the feature off, especially if my key bindings would trigger it. I've switched from using xte to using xdotools temporarily, since I believe xte does use the XTest method, would it be immune to triggering your new autohide feature?

"One more thing, no matter if Shift_L or Shift_R was pressed, you'd always get all shift keys highlighted in Onboard. The X modifier state we get has only this one Shift bit, unfortunately."

Oh that's quite alright. I only really need to know the present state of the Shift modifier anyway.

> since I believe xte does use the XTest method, would it be immune to triggering
> your new autohide feature?
Most likely yes, as long as the mouse acts as a pointer device for the button you chose. Some mice might have keyboard devices in addition to the pointer. With simple mouse button to xte mapping you should be fine. Anything coming from the XTest keyboard device will be ignored.

Sorry for taking so long. I've added both, hide on physical key-press and updating all modifiers. Most modifier changes are delayed for 1 second. I still may have to increase this, though. You can change the delay with
gsettings set org.onboard.keyboard modifier-update-delay 0.0
for example.

I'll ask Francesco for a fresh snapshot in case you still want to test it (that'd be good).

The snapshot is ready. You can get it from our PPA at
https://launchpad.net/~onboard/+archive/ubuntu/snapshots