> > 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