I'd like to suggest that the way a click is distinguished from a
click-and-drag (motion) be changed for the ``official release''.
The way it's handled now is that if the ButtonPress and ButtonRelease
events occur within ClickTime milliseconds, it's considered a Click.
If it's longer, then the click ``times out'' and it becomes a Motion.
This is often not the desired behavior, especially if you're not used
to it (I've gotten complaints from people who are more used to mwm and
4Dwm).
What these people are expecting (and what I expect, whenever I
actually do use the mouse) is for the click to become a motion only
after the mouse has started to move. That is, if I hold down the
click for fifteen seconds (having a ClickTime of 150) but don't move
the mouse at all, it should still register as a click. Not until I
move the mouse (perhaps MotionThreshold pixels) does it become a
motion (this is already there, with a hardcoded threshold of 3
pixels).
Thus a Motion would become a Click with a timeout dependent on mouse
movement, not time (which seems funny to me). ClickTime probably
should be reserved for the maximum amount of time between clicks of a
DoubleClick.
If anyone can explain to me the rationale behind the current use of
ClickTime, I'd appreciate it. I was around when the discussion was
taking place, but I don't remember the arguments.
Thanks,
Danek
PS Why does it take two keypresses to activate a menu item if the
menu was brought up by a keystroke? I've pretty much gotten used to
it, but I'm not sure that it makes sense to me. Danek
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sun Sep 24 1995 - 13:35:23 BST