On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote: > (Let me know if you want more detail somewhere here and I can rerun > my gdb tracing and/or add printfs appropriately.) > > Fortunately there is a simple reproduction program mentioned in the > Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151 > that comes from the Ubuntu compiz bug report. For convenience, I've > put it up as its own (shorter) URL: > https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py > and my fvwmrc: > https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5 > > If you have the Python GTK bindings (so that link.py runs at all), it > puts up a label box with an underlined link.
No idea, but the window with the "link" appears. > 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? The "A" context bindings actually do cause grabbing the button with any modifiers globally (in order to cut down the total number of grabs, I think). It's just a global mask of buttons to grab globally, and most applications don't care about it. There may be some change in the sequence of events the application gets, or maybe the timestamps, but its hard to say without actually seeing the events. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
