GNOME Bugzilla – Bug 644847
GdkDeviceManagerXI2: process send_event core events
Last modified: 2011-03-17 21:19:10 UTC
For bug 630842, we want to be able to fake clicks on trayicons. This doesn't work for gtk3 GtkStatusIcons though, because gtk3 only listens to XI2 pointer events by default, and there is currently no way to fake an XI2 event. This patches GdkDeviceManagerXI2 to process core events that are sent directly to the process via XSendEvent. Alternatively, we could also change the select_window_events() method to also select the core events (but still only process the ones that have send_event=True). Then it would pick up XSendEvent() calls that used an event_mask too, which makes it a bit more natural. I didn't do that though, because I didn't need it, and because it would mean that we were getting a lot of events that we were going to just ignore. Also, by doing it this way, then when XI2 XSendEvent support lands, we can change gnome-shell to send both core and XI2 events, but using the correct event_masks, and so the core events would end up not being delivered. Also: it's possible we can get rid of the existing special case for XIM, if those events are also send_events?
Created attachment 183449 [details] [review] GdkDeviceManagerXI2: process send_event core events XSendEvent doesn't currently work with XI2 events, so add code to translate core events when they have the send_event flag. (We still don't actually select for core pointer/keyboard events, so we will only receive send_event events that are sent with a 0 event_mask.)
Review of attachment 183449 [details] [review]: The code here looks fine to me. The main thing I'm a little concerned about is making sure we know and document the way forward: /* XSendEvent doesn't currently work with XI2 events, so handle * core events in this case */ Implies this code would be removed when the ability to send XI2 events was added, but that would require coordination between removing this and fixing the senders. - where an update of GTK+ could break something else. Dan suggested on IRC that perhaps the right transition strategy is that someone who wants to send an XI2 event should check what events are selected to decide what events to send. If that's our recommended way forward, the comment should be time-independent - it should describe this as a compatibility strategy but not talk about "currently".
Comment on attachment 183449 [details] [review] GdkDeviceManagerXI2: process send_event core events The patch looks fine to me, and can also help get rid of the XKeyPress/Release handling in gtkplug-x11.c (In reply to comment #2) > senders. - where an update of GTK+ could break something else. Dan suggested on > IRC that perhaps the right transition strategy is that someone who wants to > send an XI2 event should check what events are selected to decide what events > to send. If that's our recommended way forward, the comment should be > time-independent - it should describe this as a compatibility strategy but not > talk about "currently". That's actually a nice approach, for XEmbed I was thinking in proposing a XEMBED_PREFER_XI2 flag in _XEMBED_INFO, but looked quite ad-hoc to me... Given that XEmbed and old clients are here to stay, I think the point above is valid
(In reply to comment #3) > (From update of attachment 183449 [details] [review]) > The patch looks fine to me, and can also help get rid of the XKeyPress/Release > handling in gtkplug-x11.c ok, i'm not touching that (or removing the existing XIM special case in GdkDeviceManagerXI2). I'll leave it to you to figure out if anything can be simplified now.
Attachment 183449 [details] pushed as 605c383 - GdkDeviceManagerXI2: process send_event core events