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

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