richards@eng.AUburn.EDU (Eric J. Richards) (10/18/90)
Is it a single click or a double click?
I'm getting ready to have to change a program such that
a single click on a widget (say, an Athena command button)
will be different than a double click on that same widget
(a single click will bring up a menu while a double click
will redo the last selection).
I seem to remember that there is a "problem" under the
toolkit distinguishing between single and double clicks
(they both fire the corresponding handlers).
Before I re-invent the binary wheel, can someone point
me to some existing example code (either with the X11R4
distribution or on the net) that distinguishes between
<click> and <click><click> ?
If the answer doesn't appear on the mailing list, I'll
post a summary.
Thanks!
______________________________________________________________________
\ Eric Richards, Auburn University "In the darkness of future past \
\ InterNet: The magician longs to see \
\\\ richards@eng.auburn.edu One chants out between two worlds, \
\\\ BitNet: 'Fire... walk with me.'" \
\\\ erichard@ducvax.auburn.edu -- Twin Peaks \
\\\_____________________________________________________________________\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\mouse@LARRY.MCRCIM.MCGILL.EDU (10/18/90)
> I'm getting ready to have to change a program such that a single > click on a widget (say, an Athena command button) will be different > than a double click on that same widget (a single click will bring up > a menu while a double click will redo the last selection). > I seem to remember that there is a "problem" under the toolkit > distinguishing between single and double clicks (they both fire the > corresponding handlers). Close. > Before I re-invent the binary wheel, can someone point me to some > existing example code (either with the X11R4 distribution or on the > net) that distinguishes between <click> and <click><click> ? The current X architecture does not permit a client to correctly identify a single click as distinct from the first click of a double click. It is possible to fake it by doing the timing in the client, but this leads to hiccups in the presence of flaky networks (ie, in the presence of networks). Thus, the Xt attempt at handling double clicks will invoke the single-click handler on the first click, then the double-click handler on the next click (if it's within the time limit), etc. This means that the single-click action must be undoable or subsumed into the double-click action. The situation is less than ideal, I agree. I am hoping R5 improves matters. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dsr@luke.mitre.org (Douglas S. Rand) (10/19/90)
One thing to consider on Single vs. Double click is that the Single click action should be innocuous. If it isn't and the user slips up then you've made it too easy to screw himself (or herself). So find a way to combine the actions. In my app. the first click does a select and the second click edits. Neatly this means that a single click leads directly to the second click action. Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ
harp@Pkg.Mcc.COM (Christopher North-Keys) (10/25/90)
Ideally, the idea of double-click event should be unnecessary. What should be done instead is to use a proper state model instead of trying to use a time-dependent input type. For example: Let's consider the standard select(single-click)/edit(double-click) --- if the programmer has sufficient control, the use of double-clicking can be easily obviated, so: Incoming button event: If the icon is unselected: select If the icon is selected: edit I am, of course, biased --- I *despise* double clicking. It tends to be substantially more difficult to program, and forces user-specific parameters to define the single/double time threshold. The only reason it seems the double click was ever used was to compensate for crippled mice with only *ONE* button. Multibutton mice don't need this kind of cruft. -- ______________________________________________________________________________ Christopher Alex.North-Keys Associate Systems Analyst Group Talisman Harp[@Mcc.Com] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nazgul@alphalpha.com (Kee Hinckley) (10/25/90)
In article <1990Oct24.194348@Pkg.Mcc.COM> harp@Pkg.Mcc.COM (Christopher North-Keys) writes: >Ideally, the idea of double-click event should be unnecessary. What >should be done instead is to use a proper state model instead of trying >to use a time-dependent input type. ... >Incoming button event: > If the icon is unselected: select > If the icon is selected: edit Note that that doesn't solve the problem either. The highlight of a selected item involves a trip to the server. Given a server load or network problem (the same things which screw up double click) the highlight may not appear immediately and so the user may click again thinking they didn't get it the first time. Now instead of having them sometimes not get the double click action, they'll sometimes get the double click action when they wanted single - which is probably worse. Given a multi-tasking machine I don't think you can ever get this right, but building double click support into the server would help. -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
mouse@LARRY.MCRCIM.MCGILL.EDU (10/26/90)
> Ideally, the idea of double-click event should be unnecessary. What > should be done instead is to use a proper state model instead of > trying to use a time-dependent input type. This is not necessarily true. You are making some possibly invalid assumptions, which I shall elaborate on later. > For example: > Let's consider the standard select(single-click)/edit(double-click) This is standard? > if the programmer has sufficient control, the use of double-clicking > can be easily obviated, so: > Incoming button event: > If the icon is unselected: select > If the icon is selected: edit This is a nice idea, but it works only in cases like this where the single-click action can be subsumed into the double-click action. Suppose the user wants to edit that object without selecting it (in particular, without deselecting that other one over there)? > I am, of course, biased --- I *despise* double clicking. It tends to > be substantially more difficult to program, and forces user-specific > parameters to define the single/double time threshold. The only > reason it seems the double click was ever used was to compensate for > crippled mice with only *ONE* button. Multibutton mice don't need > this kind of cruft. You are assuming that there are no more commands on the mouse than there are mouse buttons. This is not necessarily true. There may be more reasonable, semantically distinct actions than there are buttons. Having only one button is not notable, except that it exacerbates this problem. (I recall one program I wrote which had seven distinct mouse commands. I was using all single and double clicks and one triple click. Stop shuddering; it's not one of the things I distribute (it wasn't even for X). In retrospect using a menu for some of them would probably have been a good idea, but I think my point is still valid.) As a simple example of the sort of problem associated with having one action implicitly perform others, take the NeXT. If I have a large window which has a small window in front of it, I cannot redirect keystrokes to the large window without also raising it in front of the small window[%]. NeXT has tied "raise window" and "type into window" together, by making the same gesture (clicking in the window) invoke both. Your sample paradigm above has the same problem in a slightly different guise: double-clicking not only edits, it also selects. (In the case of "edit" and "select" this is not as obviously bad as in the case of "raise" and "select for typein". That's not the point.) [%] There may be some way; I certainly haven't discovered it. Whether there is or not is irrelevant to my point anyway. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu