On Wed, Mar 01, 2017 at 03:10:48PM -0500, Chris Siebenmann wrote: > > > 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'.
That's just what I think. The program seems to believe it has lost focus and stops processing button events. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
