> > > I am now getting button 2 and button 3 events sent, but the
> > > modifiers are getting sent too.
> > That's per design, and was done to fix bug #304328. Maybe the fix
> > broke your case, though.
> After some consideration, I believe that that this new behaviour,
> where the modifier is sent as well as the emulated mouse button, is
> the cleanest and most "X-like" way of doing it.
Yep; I've had a closer look and there's little chance to do it any other
> I looked at the mouseemu source code, and spent some time reading
> various X documentation. Based on my limited understanding of X, it
> seems there is no clean way of mulitplexing modifier keys to fulfil
> both tasks (mouse button emulation, but normal modifier behviour for
> other keypresses). I imagine that these issues are already
The state of the modifier key is kept by the X server, so you need to send
the modifier before you send a regular key event (disregarding mouse
events for a moment here). We could postpone the modifier event until we
know what other event follows, but that's equally messy.
> Later on today I will have at look at the behaviour of Apple X11, and
> check out what events it is generating.
Right, they must have solved this some way already.
> I think that out of all the workarounds, the suggestion to send a
> modifier up, mouse button down sequence would be the best. But still,
> like you suggest, it will get quite messy. I can imagine a few cases
> in which this will lead to confusing and unintended behaviours.
Should not really happen, because mouseemu intercepts all input events
hopefully, and hence can ensure they get sent in the correct order.
Meaning you cannot sneak a key event in between the mod up, mouse down,
mod down sequence. IIRC X doesn't mind if the modifier state changes while
a button is kept down. Either way, there's limits to what extent you can
emulate mouse buttons using modifier keys.
I'll cook up some experimental hack for you to test.