Re: FVWM: Mouse click problem with Corebird plus my FVWM configuration

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