> > If you click on the link, it's supposed to print something like: > > > > link <gtk.Label object at 0x7f64ef58dd70 (GtkLabel at 0x55f69d5c4d40)> > > http://gtk.org > > In a configuration with a Mouse 1 binding that includes the Window > > context (so W or A), the link can't be activated by clicking mouse-1 > > and link.py prints nothing. You can however get it to print something > > by clicking on the link and then hitting Return to activate the link > > through the keyboard. > > Okay, this is reproduceable. I know nothing about python or Gtk+, > so this may be easy, but here, when you click on the window, xev > prints no ButtonPress or ButtonRelease events at all neither with > nor without the binding. Is there a way so that the program > prints all events it sees?
I don't know if there's a way to get GTK to do that, but I can use the blunt hammer of xtrace here: https://xtrace.alioth.debian.org/ Based on this, the link.py script is seeing LeaveNotify and EnterNotify events before the ButtonPress event. The initial numbers here are relative time since program start in seconds, and I left the program idle for several seconds to make sure things would stand out (and indeed they do): 5.042 000:>:0206: Event LeaveNotify(8) detail=Ancestor(0x00) mode=Grab(0x01) flags=same-screen time=0x05ee50ba root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=Button1 [link.py wakes up and wakes a ton of requests and RENDER-Requests] 5.043 000:>:0235: Event UnmapNotify(18) event=0x00600043 window=0x00600043 from-configure=false(0x00) 5.045 000:>:0235: Event VisibilityNotify(15) window=0x00600003 state=Unobscured(0x00) 5.046 000:>:0235: Event Expose(12) window=0x00600003 x=145 y=117 width=38 height=1 count=0x0004 5.046 000:>:0235: Event Expose(12) window=0x00600003 x=144 y=118 width=40 height=1 count=0x0003 5.046 000:>:0235: Event Expose(12) window=0x00600003 x=143 y=119 width=42 height=33 count=0x0002 5.046 000:>:0235: Event Expose(12) window=0x00600003 x=144 y=152 width=40 height=1 count=0x0001 5.046 000:>:0235: Event Expose(12) window=0x00600003 x=145 y=153 width=38 height=1 count=0x0000 5.046 000:>:0235: Event EnterNotify(7) detail=Ancestor(0x00) mode=Ungrab(0x02) flags=same-screen time=0x05ee50bd root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=Button1 5.046 000:>:0235: Event ButtonPress(4) button=left button(0x01) time=0x05ee50ba root=0x0000026d event=0x00600003 child=None(0x00000000) root-x=702 root-y=319 event-x=128 event-y=102 state=0 same-screen=true(0x01) (Some of those expose events are presumably because of the various requests and render requests it issued immediately after the LeaveNotify.) In looking at this carefully, I did notice another anomaly in link.py's behavior (which you may have also noticed). When I initially move the mouse pointer over the actual link, it turns from a plain pointer into a hand-pointer, presumably to signal that this is a clickable link, and the program also pops up a tooltip for the link destination. When I click on the link and nothing happens, this immediately changes back to the regular pointer; in fact, this change happens on the button press (which I can see if I click down and hold). This doesn't happen with working clicks, where a button-press leaves the cursor unchanged. I wonder if GTK is (mis-)processing the LeaveNotify here as 'the mouse pointer is leaving the link', instead of 'mouse has been grabbed from me'. - cks