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

On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote:
> 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.

There's another strange symptom that seems to point to a button
handling problem in the library, as it occurs even without such a
"trigger" binding.  Without a "mouse 3 a ..." binding:

  * Move the pointer over "link".  The test gets highlighted in
    white.
  * Push button 3.  The text gets a dark grey background, and a
    popup menu opens.
  * Hit the "Escape" key to close the popup.  The text background 
    is light grey now.
  * Do not move the pointer now; otherwise the problem goes away.
  * Clicking with button 3 again does nothing.  Pressing the
    "Return" key still works.

It seems the library gets confused about the window's state.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt