dan@watson.ibm.COM (Walt Daniels) (10/17/89)
I think I prefer spacially resolved double clicks rather than time resolved double clicks. These can be handled entirely on the client side with only the two button events coming from the server. Thus the client should (if is implements double clicks at all) enter a state machine after a click and not do anything until either another click near the first click spacially, sufficient mouse motion to be outside the space of the first click, a keystroke, or some longish time. In general I think double clicks are a poor human interface and are really a poor substitute for a mouse with sufficient buttons. The reason it is a poor interface is that the program can never be responsive to the user until the second event whether time or space resolved. In other words one click can never have a useful meaning other than enter complicated state machine. Walt Daniels
jta@lcc.UUCP (Jim Anderson) (10/20/89)
Of course, after the first click you could wait for the double click interval to expire then do an XSync before checking the event queue for the second click event. This would seem to solve the network latency problem. There are lots of variations on this theme.
dan@watson.ibm.COM (Walt Daniels) (10/20/89)
Although the history of double clicks is interesting it is not germain to changing the environment from a single machine to the network situation of today. If one really wants a powerful mouse, why not go back to Doug Englebart's original mouse which had enough keys to use as a typewriter by exploiting cords. I don't remember if it used double clicks or not. In a network environment one must reinvestigate the usefulness of all the user interaction paradigms since the timing changes dramatically. It is not even so much the absolute value of the time between events as their potential variability. I will trade all sorts of things for consistent performance (after all that is a large part of the reason for the success of pc's and workstations over mainframes.) Even simple things like keyboard typeahead are very hard to support in a windowing environment. I frequently switch between a host session in a window and other applications which are designed to exploit X. Most of my host work fully supports typeahead (and I need it because the response time is slower than my typing speed.) In X, some applications support type ahead and other do not which makes it very hard to anticipate. Xterm supports typeahead; vi supports typeahead (because it is really tty based); but my favorite editor which trys to exploit the advantages of windows does not support typeahead fully. Once the window is up and ready, I can type ahead but if I start typing while the file is still be read and no window is present, those key strokes wind up in the xterm from which I invoked the editor until some variable magic point. So for small local files I usually get away with typeahead and for remote or large files I wind up twisted in knots. Variability is intolerable. Perhaps some X guru can tell me how to fix my editor to get all the keys but I suspect it is hard or impossible since there is certainly a period of time between the invocation and the call to Xcreatewindow. Walt Daniels IBM Research
montnaro@sprite.crd.ge.com (Skip Montanaro) (10/20/89)
In article <101989.155135.dan@watson.ibm.com> dan@watson.ibm.COM (Walt Daniels) writes: If one really wants a powerful mouse, why not go back to Doug Englebart's original mouse which had enough keys to use as a typewriter by exploiting cords. Look how hard it is to decide what functions to assign to 1-3 button mice, whether or not to double-click, which button raises which menus, whether or not modifier keys must be pressed, and what grief is caused when a vendor fiddles with the peripheral keys on the keyboard. If you're going to get into multi-button mice in a big way (> 4 or 5 keys, chording, multi-clicks, ...), you absolutely have to have standards, otherwise people won't be able to switch between equipment from different vendors, and different application packages would almost certainly apply different semantics to the buttons. As an aside, my boys (six & seven) often triple- or quadruple-click when launching applications on the Mac. (Applications don't start fast enough for them I guess. :-) Imagine what grief might have been caused if Apple had decided to get carried away with the multi-click stuff... -- Skip Montanaro (montanaro@crdgw1.ge.com)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/23/89)
In article <MONTNARO.89Oct20092004@sprite.crd.ge.com>, montnaro@sprite (Skip Montanaro) writes: > If you're going to get >into multi-button mice in a big way (> 4 or 5 keys, chording, multi-clicks, >...), you absolutely have to have standards, One standard is to NOT define them, and let the user have them available as a means of extending his/her personal interface. Example: Microsoft Word 4.0 for the Mac allows the user to add key and menu accelerators. Great Idea! Another interesting idea is to have a macro facility in (or above) the window manager that allows you to define Shift-Meta-Double-Click-MiddleMouse to mean a particular operation. The Mac has a standard utility that can be used to map keystrokes into mouse actions. There are global macros that work for all programs, and per-application macros. This allows you to map an a single action to several applications, even if they use different conventions. >As an aside, my boys (six & seven) often triple- or quadruple-click when >launching applications on the Mac. Very true. Also - when my son uses HyperCard, he double-clicks when a single click will work. This shows the problem with using double-clicks in a non-intuitive manner. IMHO If multiple-clicks were to become a standard, it should be used for accelerators, unnecessary to know about but useful if available. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett