Happens.
As long as the action is supposed to fire on press events, this is logically unresolvable.
You cannot press the mouse twice w/o pressing it once ;-)
The implementation would have to be changed to fire after the fullscreen interval what would make the system seem to react sluggish. /me votes for "CANTFIX"
Iff ("and only if") there's a "delay" for the single click action, the doubleclick could kill the pending timer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
but really: MouseN means just "press it and hold it". ClickN is a real click (press + release), and with intention ClickN trigger are also "don't move the mouse".
so, to tackle the problem: maybe a mouse-press longer than n milliseconds will render the "double" modifier useless. @thomas: what do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem here is however the desire to do perform a double (press, click seems to fail, probably due to enter/leave events by passive grab?) action and not a single action.
This requires prediction on whether there'll be a second press/click (which qualifies for a "double") which is simply ipossible.
A postdiction however mandates a delay between a press/click and the action to be performed (to rule out this is part of a doubleclick) which imo can no way be a general behavior, so the only doable thing would be to map pending DelaydCmd's on single and cancel them on actual double invocation.
Whether that fits the original request (ie. he'd be willing to accept some 250ms delay between press and iconification) i can't say.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
which version of fluxbox? which os? etc etc.
keys-file
init-file
Fluxbox version: 1.3.2
GIT Revision: e8f2e964c6a88e357bbc09b66cd3490cf9eed5ef
Compiled: Nov 3 2012 03:16:29
Compiler: GCC
Compiler version: 4.4.7
Defaults:
menu: /usr/local/share/fluxbox/menu
style: /usr/local/share/fluxbox/styles/bloe
keys: /usr/local/share/fluxbox/keys
init: /usr/local/share/fluxbox/init
nls: /usr/local/share/fluxbox/nls
Compiled options (- => disabled):
BIDI
-DEBUG
EWMH
IMLIB2
NLS
REMEMBER
RENDER
SHAPE
SLIT
TOOLBAR
XFT
-XINERAMA
XMB
XPM
I forgot: Debian Linux squeeze/wheezy i386
I have the same problem with version 1.3.2 and on Slakware 14.1.
OnToolBar Double Mouse1 :Exec /path/to/application
Please resolve it if possible!
Last edit: bulkomorowski 2013-11-16
Happens.
As long as the action is supposed to fire on press events, this is logically unresolvable.
You cannot press the mouse twice w/o pressing it once ;-)
The implementation would have to be changed to fire after the fullscreen interval what would make the system seem to react sluggish. /me votes for "CANTFIX"
Iff ("and only if") there's a "delay" for the single click action, the doubleclick could kill the pending timer.
"SlowClick" :)
but really: MouseN means just "press it and hold it". ClickN is a real click (press + release), and with intention ClickN trigger are also "don't move the mouse".
so, to tackle the problem: maybe a mouse-press longer than n milliseconds will render the "double" modifier useless. @thomas: what do you think?
The problem here is however the desire to do perform a double (press, click seems to fail, probably due to enter/leave events by passive grab?) action and not a single action.
This requires prediction on whether there'll be a second press/click (which qualifies for a "double") which is simply ipossible.
A postdiction however mandates a delay between a press/click and the action to be performed (to rule out this is part of a doubleclick) which imo can no way be a general behavior, so the only doable thing would be to map pending DelaydCmd's on single and cancel them on actual double invocation.
Whether that fits the original request (ie. he'd be willing to accept some 250ms delay between press and iconification) i can't say.