FVWM: Mouse click problem with Corebird plus my FVWM configuration

[Chris Siebenmann]

 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

In subsequent testing I've determined that this happens with the latest
git tip (as well as the FVWM 2.6.6 that Fedora has), but only when using
my FVWM configuration or a cut-down version of it. If I start either
version of fvwm as 'fvwm -f /dev/null', clicking on links in Corebird
works fine.

I have put my current cut-down testing version of my fvwm configuration
on the web as
https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5

This deletes all of my modules and most of my menus (and the various
functions used by both), leaving active mostly a collection of mouse
and keyboard bindings and styles (and some settings). Testing this under
Xephyr reproduces the problem all the time.

Does anyone have any idea of where to start looking for the binding or
setting that might be doing this? I hope this is a (fvwm) bug that can
be fixed in the long run, but in the short run maybe I/we can at least
identify what FVWM setting I'm using that causes this (and maybe I can
live without it).

Thanks in advance.

- cks

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

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
 wrote:
> Hello,
>
> FvwmIconMan still reports Hint warnings even with the patchs applied.
>

I wrote this small patch that has FvwmIconMan wait until the window
has resized to set the window hints. This is in the lines of Dominik
Vogt's patch, but waits until FvwmIconMan has fully resized to run
fix_manager_size() to set the window hints. My tests here no longer
seem to tiger the warnings like it still sometimes did.

As an additional thought, talking to Thomas Adam about the patch in
#fvwm, he mentioned that the issue is more FVWM being overly cautious
and the fix should be in how fvwm handles size hint warnings over
working with FvwmIconMan to avoid triggering them.

I don't know enough about the issue to say which is more appropriate,
but here is a patch that stops the warnings from being triggered in my
tests.

jaimos
From 227d7ea2597ec3fec304c53934fcc41773ab7e89 Mon Sep 17 00:00:00 2001
From: Jaimos Skriletz 
Date: Tue, 28 Feb 2017 17:43:12 -0700
Subject: [PATCH 1/1] Wait until FvwmIconMan is resized to set window HINTS

---
 modules/FvwmIconMan/xmanager.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/modules/FvwmIconMan/xmanager.c b/modules/FvwmIconMan/xmanager.c
index 58eaaedc..b4efe890 100644
--- a/modules/FvwmIconMan/xmanager.c
+++ b/modules/FvwmIconMan/xmanager.c
@@ -439,6 +439,16 @@ static void resize_window(WinManager *man)
 }
 MyXUngrabServer(theDisplay);
   }
+
+  // Wait until the window has resised to fix the HINTS.
+  // counter is used to break an infinte loop.
+  XWindowAttributes attribs;
+  int counter = 2;
+  while ( counter && (attribs.width != man->geometry.width ||
+  attribs.height != man->geometry.height)) {
+XGetWindowAttributes(theDisplay, man->theWindow, );
+counter--;
+  }
   fix_manager_size(man, man->geometry.width, man->geometry.height);
 }
 
-- 
2.11.0