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

[Dominik Vogt]

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   
> > > 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=0x026d 
> event=0x0063 child=None(0x) 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=0x0063 
> state=Unobscured(0x00)
>   5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=117 
> width=38 height=1 count=0x0004
>   5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=118 
> width=40 height=1 count=0x0003
>   5.046 000:>:0235: Event Expose(12) window=0x0063 x=143 y=119 
> width=42 height=33 count=0x0002
>   5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=152 
> width=40 height=1 count=0x0001
>   5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=153 
> width=38 height=1 count=0x
>   5.046 000:>:0235: Event EnterNotify(7) detail=Ancestor(0x00) 
> mode=Ungrab(0x02) flags=same-screen time=0x05ee50bd root=0x026d 
> event=0x0063 child=None(0x) 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=0x026d event=0x0063 child=None(0x) 
> 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

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

[Chris Siebenmann]

> > If you click on the link, it's supposed to print something like:
> > 
> > link   
> > 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=0x026d 
event=0x0063 child=None(0x) 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=0x0063 
state=Unobscured(0x00)
5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=117 
width=38 height=1 count=0x0004
5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=118 
width=40 height=1 count=0x0003
5.046 000:>:0235: Event Expose(12) window=0x0063 x=143 y=119 
width=42 height=33 count=0x0002
5.046 000:>:0235: Event Expose(12) window=0x0063 x=144 y=152 
width=40 height=1 count=0x0001
5.046 000:>:0235: Event Expose(12) window=0x0063 x=145 y=153 
width=38 height=1 count=0x
5.046 000:>:0235: Event EnterNotify(7) detail=Ancestor(0x00) 
mode=Ungrab(0x02) flags=same-screen time=0x05ee50bd root=0x026d 
event=0x0063 child=None(0x) 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=0x026d event=0x0063 child=None(0x) 
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

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

[Dominik Vogt]

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

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

[Dominik Vogt]

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

Note:  This bug is present even in the complete absence of a
window manager, when the program runs on a plain, unmanaged  X
screen.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

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

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

[Chris Siebenmann]

> > Unless I have a simple test application and a configuration
> > that exhibits that behaviour I cannot do much about it.
> > Would you be able to fvwm in Xnest and debug through
> > events.c:__handle_bpress_on_managed() to see what actually happens?
>
> By the way, have you tried to get the application developers' opinion?
> From the xev output is seems that the button events are reported to
> the program, so why doesn't it react to them?

 This appears to be something that's happening in the guts of the
GTK+ library, not in application specific code. As far as I know from
looking at the source code, Corebird (and Darktable) are delegating all
rendering and event handling to GTK+'s HTML-capable widgets and only
responding to activities that those library widgets report back.

 This may be a GTK+ issue, but even if the GTK+ people accept this as a
bug (and they may argue very much against it, since all of this works
in their officially approved environments and other window manager
environments and so on) it's not going to get fixed any time soon in
widely deployed systems, many of which will be running current (or old)
GTK+ versions for years to come.

- cks

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

[Chris Siebenmann]

> The only other reason fvwm grabs a button is for focus handling in
> focus.c:__focus_grab_one_button().  The only possible reason I
> could think of is that the application does not accept focus so
> that grab never gets removed.  Have you tried
> 
>   Style * Lenience
> 
> as Dan suggested?
> 
> For further debugging, does the problem go away with
> 
>   style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick

 With both 'Style *' settings (and with my usual 'SloppyFocus' setting
commented out), the problem is still there. I also tested with just
'Style * Lenience' and the problem is also still there.

> Unless I have a simple test application and a configuration
> that exhibits that behaviour I cannot do much about it.
> Would you be able to fvwm in Xnest and debug through
> events.c:__handle_bpress_on_managed() to see what actually happens?

 The flow appears to be:
__handle_bpress_on_managed()
  -> __handle_focus_raise_click()
 -> __check_click_to_focus_or_raise()
returning f.do_focus and f.do_raise both 0

  f.do_forbid_function is 0, so we check bindings.
-> __handle_bpress_action() which returns false
  if (IS_SCHEDULED_FOR_RAISE(fw)) is false; we skip that block
  f.do_swallow_click is false, so we call:
XAllowEvents(dpy, ReplayPointer, CurrentTime)
XFlush(dpy)
  ... and return.

(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. If you click on the link,
it's supposed to print something like:

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

- cks

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

[Dominik Vogt]

On Wed, Mar 01, 2017 at 07:02:55PM +0100, Dominik Vogt wrote:
> On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote:
> > > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> > > > 
> > > > > >  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > > > file (from the URL) *except* either:
> > > > > > 
> > > > > > Mouse   1   A   MS  Iconify
> > > > > > or
> > > > > > Mouse   1   A   M   Raise
> > > 
> > > Try
> > > 
> > >   mouse 1 tsifw ...
> > > 
> > > instead.  Limit the context a binding applies to to what is
> > > needed.  It's inefficient and interferes with other programs'
> > > bindings.  Or do you really iconify windows by clicking on the
> > > root window?
> > 
> >  I've now tested and the problem happens with just:
> > 
> > Mouse 1 W   MS  Iconify
> > 
> > ... which is about the minimal binding, since I really do want to
> > iconify windows with meta-shift-1 anywhere inside them.
> 
> Referring to the other message, I disagree with the analysis
> there.  Fvwm grabs only the modifier combinations on windows that
> it needs, i.e. the ones that are present in the binding.  See
> libs/Bindings.c:GrabWindowButton().  Unless you have you have
> something like
> 
>   IgnoreModifiers MS
> 
> The only other reason fvwm grabs a button is for focus handling in
> focus.c:__focus_grab_one_button().  The only possible reason I
> could think of is that the application does not accept focus so
> that grab never gets removed.  Have you tried
> 
>   Style * Lenience
> 
> as Dan suggested?
> 
> For further debugging, does the problem go away with
> 
>   style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick
> 
> Unless I have a simple test application and a configuration that
> exhibits that behaviour I cannot do much about it.  Would you be
> able to fvwm in Xnest and debug through
> events.c:__handle_bpress_on_managed() to see what actually
> happens?

By the way, have you tried to get the application developers'
opinion?  From the xev output is seems that the button events are
reported to the program, so why doesn't it react to them?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Wed, Mar 01, 2017 at 09:43:58AM -0500, Chris Siebenmann wrote:
> > On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> > > 
> > > > >  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > > file (from the URL) *except* either:
> > > > > 
> > > > >   Mouse   1   A   MS  Iconify
> > > > > or
> > > > >   Mouse   1   A   M   Raise
> > 
> > Try
> > 
> >   mouse 1 tsifw ...
> > 
> > instead.  Limit the context a binding applies to to what is
> > needed.  It's inefficient and interferes with other programs'
> > bindings.  Or do you really iconify windows by clicking on the
> > root window?
> 
>  I've now tested and the problem happens with just:
> 
>   Mouse 1 W   MS  Iconify
> 
> ... which is about the minimal binding, since I really do want to
> iconify windows with meta-shift-1 anywhere inside them.

Referring to the other message, I disagree with the analysis
there.  Fvwm grabs only the modifier combinations on windows that
it needs, i.e. the ones that are present in the binding.  See
libs/Bindings.c:GrabWindowButton().  Unless you have you have
something like

  IgnoreModifiers MS

The only other reason fvwm grabs a button is for focus handling in
focus.c:__focus_grab_one_button().  The only possible reason I
could think of is that the application does not accept focus so
that grab never gets removed.  Have you tried

  Style * Lenience

as Dan suggested?

For further debugging, does the problem go away with

  style * clicktofocus, clicktofocusraises, ClickToFocusPassesClick

Unless I have a simple test application and a configuration that
exhibits that behaviour I cannot do much about it.  Would you be
able to fvwm in Xnest and debug through
events.c:__handle_bpress_on_managed() to see what actually
happens?

> > > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > > > in xev
> > 
> > Forget about these; that's just how X works.
> 
>  Is it possible that some part of GTK+ doesn't like this sequence
> of events and ignores ButtonPress/ButtonRelease as a result?

No.

> It is relatively striking to me how correlated things are here.

These events are generated as a side effect of button presses by
design of the X protocol.  An application that cannot deal with
them is broken.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Chris Siebenmann]

> > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > > in xev
> 
> Forget about these; that's just how X works.

 I dusted off old memories about the patches that I'm carrying in my
home fvwm binary and not my work one, and I think that this has come
up before and had a patch proposed before. If I'm right, see this
fvwm-workers discussion from early September 2014:

https://www.mail-archive.com/fvwm-workers@fvwm.org/msg03528.html

This change was reverted here:
https://www.mail-archive.com/fvwm-workers@fvwm.org/msg03596.html

apparently because of this issue:
https://www.mail-archive.com/fvwm-workers@fvwm.org/msg03593.html

This came out of my May 2013 report of a very similar issue with
Darktable, which is also a GTK+ application. At the time I wound up
localizing it to those same Mouse 1 'A' bindings I have (in email between
me and Thomas Adam, not captured in the mailing list archives). The
initial fvwm thread about it is here:

http://www.mail-archive.com/fvwm@fvwm.org/msg02464.html

This is apparently also a Debian bug report with somewhat more
specific details about the GTK+ bits with problems, from 2011:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151

I've built a version of git tip fvwm with the patch from Thomas
Adam and it appears to fix this issue for me (although presumably
the patch still has the issue that caused it to be reverted).

- cks

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

[Chris Siebenmann]

> On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> > 
> > > >  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > > file (from the URL) *except* either:
> > > > 
> > > > Mouse   1   A   MS  Iconify
> > > > or
> > > > Mouse   1   A   M   Raise
> 
> Try
> 
>   mouse 1 tsifw ...
> 
> instead.  Limit the context a binding applies to to what is
> needed.  It's inefficient and interferes with other programs'
> bindings.  Or do you really iconify windows by clicking on the
> root window?

 I've now tested and the problem happens with just:

Mouse 1 W   MS  Iconify

... which is about the minimal binding, since I really do want to
iconify windows with meta-shift-1 anywhere inside them.

> > > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > > in xev
> 
> Forget about these; that's just how X works.

 Is it possible that some part of GTK+ doesn't like this sequence
of events and ignores ButtonPress/ButtonRelease as a result? It is
relatively striking to me how correlated things are here.

- cks

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

[Dominik Vogt]

On Tue, Feb 28, 2017 at 08:42:38PM -0500, Chris Siebenmann wrote:
> 
> > >  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > > file (from the URL) *except* either:
> > > 
> > >   Mouse   1   A   MS  Iconify
> > > or
> > >   Mouse   1   A   M   Raise

Try

  mouse 1 tsifw ...

instead.  Limit the context a binding applies to to what is
needed.  It's inefficient and interferes with other programs'
bindings.  Or do you really iconify windows by clicking on the
root window?

> > > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > > in xev

Forget about these; that's just how X works.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Chris Siebenmann]

> >> When you click a mouse it should generate 2 X11 events:
> >> 
> >> ButtonPress
> >> ButtonRelease
> >
> >  I've just used xev to confirm that I see ButtonPress and ButtonRelease
> > events. However, what I have discovered is that I see additional events
> > with my FVWM configuration. Immediately before a ButtonPress, I also get:
> >
> > ButtonRelease event, serial 33, synthetic NO, window 0x61,
> >root 0x26d, subw 0x0, time 672491078, (62,72), root:(856,280),
> >state 0x100, button 1, same_screen YES
> 
> The first event you see SHOULD be ButtonPress.
> Are you sure there is a release before the press?
> If so, bad hardware.
> 
> (Still guessing.)

 Sorry, I failed to be clear in what I wrote (my fault). The sequence
of events for a button press and release is:

LeaveNotify
EnterNotify
KeymapNotify
ButtonPress
ButtonRelease

I mentioned the preceeding ButtonRelease to show that there was nothing
in between this sequence, and I accidentally left out the ButtonRelease
in my transcript.

 The LeaveNotify, EnterNotify, and KeymapNotify happen in a burst
immediately before the ButtonPress (and all of them happen as I press the
button down). The ButtonRelease happens after I let up the button, so I
can create as much delay as I want between ButtonPress and ButtonRelease
by continuing to hold it down.

> >  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> > file (from the URL) *except* either:
> > 
> > Mouse   1   A   MS  Iconify
> > or
> > Mouse   1   A   M   Raise
> > 
> > then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> > in xev and clicking on links no longer works in Corebird.
> > 
> > If I comment out those two bindings but leave everything else commented
> > in, I don't see any problems.
> 
> Try using another modifier besides Meta.
> X11 looks for a KeyPress event to know Meta is on and KeyRelease
> to know it is off.  Use xev to verify that pressing Meta only produces
> a press followed by a release.

 I've verified that any modifier appears to do this, and that all of
my modifiers produce only KeyPress then KeyRelease events when pressed
down and then released by themselves.

(And, to be clear, I'm not holding down any modifiers when doing these
button clicks.)

 Also, it occurred to me that I have 'A' bindings for Mouse 2 and Mouse
3 as well. Testing with xev shows that both of these mouse buttons also
produce the same burst of LeaveNotify, EnterNotify, and KeymapNotify
immediately before a button-down event in xev.  This is exactly what
I'd expect if there is something in how fvwm processes these 'Anywhere'
bindings that is causing these events to be generated.

- cks

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

[Dan Espen]

Chris Siebenmann  writes:

>> Chris Siebenmann  writes:
>> 
>> >  Corebird is a Linux/GTK Twitter client:
>> >https://corebird.baedert.org/
>> >
>> > In attempting to use the current version on Fedora 25, I have uncovered
>> > a weird oddity where I cannot click links with the left mouse button when
>> > using my FVWM configuration. Corebird recognizes that I have clicked and
>> > will do things like select text, but does not see it as quite whatever
>> > is needed to make it see things as a click that activates the link. A long
>> > discussion of what I can and can't do is in my initial Fedora bug report:
>> >https://bugzilla.redhat.com/show_bug.cgi?id=1425611
>> 
>> My guess, bad hardware.
>> 
>> When you click a mouse it should generate 2 X11 events:
>> 
>> ButtonPress
>> ButtonRelease
>
>  I've just used xev to confirm that I see ButtonPress and ButtonRelease
> events. However, what I have discovered is that I see additional events
> with my FVWM configuration. Immediately before a ButtonPress, I also get:
>
> ButtonRelease event, serial 33, synthetic NO, window 0x61,
>root 0x26d, subw 0x0, time 672491078, (62,72), root:(856,280),
>state 0x100, button 1, same_screen YES

The first event you see SHOULD be ButtonPress.
Are you sure there is a release before the press?
If so, bad hardware.

(Still guessing.)

>  If I comment out all Mouse 0 and 1 bindings from my fvwmrc-2.5
> file (from the URL) *except* either:
> 
>   Mouse   1   A   MS  Iconify
> or
>   Mouse   1   A   M   Raise
> 
> then I see the extra LeaveNotify / EnterNotify / KeymapNotify sequence
> in xev and clicking on links no longer works in Corebird.
> 
> If I comment out those two bindings but leave everything else commented
> in, I don't see any problems.

Try using another modifier besides Meta.
X11 looks for a KeyPress event to know Meta is on and KeyRelease
to know it is off.  Use xev to verify that pressing Meta only produces
a press followed by a release.

-- 
Dan Espen