Bug#722736: fvwm: scrolling with the mouse over a button is seen as a (double) click

2016-12-01 Thread Jaimos Skriletz 
On Tue, 26 Nov 2013 10:35:55 +0100 Vincent Lefevre  wrote:
> On 2013-11-26 00:12:09 -0800, Vincent W. Chen wrote:
> > On Sat, Oct 26, 2013 at 4:50 PM, Vincent Lefevre  wrote:
> > > On 2013-10-25 17:42:54 -0700, Vincent W. Chen wrote:
> > >> > No, "Mouse 4" and "Mouse 5" would still be allowed, but "Mouse 0" 
> > >> > should
> > >> > be equivalent to "Mouse 1 or 2 or 3". This makes more sense.
> > >> >
>
> > > Currently the man page is still buggy. Or perhaps the intent of
> > > "Mouse 0" is not to include the scroll up & down events (just like
> > > with mouse navigation in menus).
> > >
> > Would it be sufficient if the manpage is changed to read "Pressing any
> > mouse button (other than buttons 4 and 5) while a menu is open ..."?
>
> The manpage should be changed. But I also think that there should be
> a warning to say that "Mouse 0" will also include mouse wheel events
> in practice and that a user who don't want such events to be take
> into account mustn't use "Mouse 0".
>

I have looked into this a little bit and don't think there is an
inconsistency. The issue I see is there are default bindings for menus
configured in /usr/share/fvwm/ConfigFvwmDefaults. The four lines of
interest are

Mouse 0 MI A MenuSelectItem
Mouse 0 MTS A MenuLeaveSubmenu
Silent Mouse 4  MIT A MenuScroll -1
Silent Mouse 5  MIT A MenuScroll +1

This first defines all mouse buttons via "Mouse 0" do something, then
defines additional bindings to buttons 4 and 5. So it isn't that fvwm
is treating bindings in Menus differently, but the defaults are
configured so the mouse 4 and 5 on a menu act differently than the
other mouse buttons. I was able to remove the two Mouse 4 and Mouse 5
bindings above and then redefine the Mouse 0 bindings in the menu and
was able to trigger menu items from the scroll wheel.

I don't see this as a bug, but working as designed.

I have also found in the manpage under Mouse Navigation talking about
how the mouse wheel is configured to scroll by default. Additionally I
have found under the Mouse description in the manpage that "If Button
is zero then any button performs the specified function." So the
manpage is correctly describing the behavior. Additionally this means
any not just buttons 1-5, it is just those are the only buttons fully
supported. This could also cause the option to be triggered for
buttons > 5, it is just >5 buttons are not always fully supported for
all things in X.

Does this resolve the issue, or do you still think the manpage needs
to be more clear on this behavior?

I do agree that having to write multiple lines to get what you need
configured is not ideal, but current fvwm config syntax won't allow it
and fvwm2 development is mostly ended so we have to use the config
options in its current state.

jaimos

Bug#722736: fvwm: scrolling with the mouse over a button is seen as a (double) click

2013-09-13 Thread Vincent Lefevre 
Package: fvwm
Version: 1:2.5.30.ds-1.1
Severity: important

When I scroll with the mouse over a title-bar button, Fvwm sees
this as a click (or double click). In my case, the double click
deletes the window and I lose data. :(

Here are my mouse bindings:

Mouse 1 R   A   Menu Apps Nop
Mouse 2 R   A   Menu ifelse(AY,1,/Debian,Hosts) Nop
Mouse 3 R   A   Menu Quit-Misc Nop
Mouse 1 R   M   Menu Misc Nop
Mouse 2 R   M   Menu WindowOps Nop

Mouse 0 1   A   Windowops-or-Die
Mouse 1 2   A   Raise-and-Fct Maximize 0 100
Mouse 2 2   A   Maximize 0 grow
Mouse 3 2   A   Maximize 0 100
Mouse 0 3   A   Stick
Mouse 1 4   A   Raise-and-Fct Maximize 100 100
Mouse 2 4   A   Maximize grow grow
Mouse 3 4   A   Maximize 100 100
Mouse 0 5   A   Iconify
Mouse 0 6   A   Iconify

Mouse 2 TISFA   PopUp WindowOps
Mouse 2 TISFM   Module FvwmIdent

Mouse 1 T   A   Raise-and-Move
Mouse 3 T   A   Lower-or-Move
Mouse 1 I   A   Move-or-Iconify
Mouse 3 I   A   Move-or-Iconify
Mouse 1 SF  A   Raise-and-Resize
Mouse 3 SF  A   Lower-or-Resize
Mouse 1 SF  M   Raise-and-Move
Mouse 3 SF  M   Lower-or-Move

Mouse 4 R   A   Nop
Mouse 5 R   A   Nop

This can't explain the behavior.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages fvwm depends on:
ii  libc6   2.17-92+b1
ii  libcairo2   1.12.16-1
ii  libfontconfig1  2.10.2-2
ii  libfribidi0 0.19.5-2
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.4-1
ii  libice6 2:1.0.8-2
ii  libperl4-corelibs-perl  0.003-1
ii  libpng12-0  1.2.49-4
ii  libreadline66.2+dfsg-0.1
ii  librplay3   3.3.2-14
ii  librsvg2-2  2.36.4-2
ii  libsm6  2:1.2.1-2
ii  libstroke0  0.5.1-6
ii  libtinfo5   5.9+20130608-1
ii  libx11-62:1.6.1-1
ii  libxcursor1 1:1.1.14-1
ii  libxext62:1.3.2-1
ii  libxft2 2.3.1-1
ii  libxinerama12:1.1.3-1
ii  libxpm4 1:3.5.10-1
ii  libxrender1 1:0.9.8-1
ii  perl5.18.1-4
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages fvwm recommends:
ii  fvwm-icons20070101-2
ii  libx11-protocol-perl  0.56-4
ii  perl-tk   1:804.031-1+b1

Versions of packages fvwm suggests:
ii  cpp  4:4.8.1-3
pn  fvwm-themes  none
ii  m4   1.4.16-5
ii  menu 2.1.46
pn  wm-icons none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722736: fvwm: scrolling with the mouse over a button is seen as a (double) click

2013-09-13 Thread Vincent Lefevre 
On 2013-09-13 22:04:26 +0200, Vincent Lefevre wrote:
 When I scroll with the mouse over a title-bar button, Fvwm sees
 this as a click (or double click). In my case, the double click
 deletes the window and I lose data. :(
[...]
 This can't explain the behavior.

Well, scrolling generates button 4 and 5 events, but it is well known
that this is for scrolling in practice; they do not correspond to
real buttons. So, regarding such an event as a real button is not
what the user expects (in practice, this makes no sense).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org