SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - tweak
Viewing Issue Advanced Details
1039 Any minor always 04-04-05 18:17 04-28-05 06:02
0001039: Click event order
In a double click, the first click should signal a click and the second should signal a double click. Currently, the double click arrives before the click:
 mouseDown: [14@8 mouseDown red 19046261]
 mouseDown: [14@8 mouseDown red 19046407]
 double click: [14@8 mouseDown red 19046407]
 click: [256@101 mouseUp 19046491]
What should happen is:
- down
- up + click
- down + double click
- up
has duplicate 0002994resolved bert mouseclick event order 
related to 0001038assigned bert Triple click 
related to 0001077assigned bert clicking kaput 
 ClickalaBert.gif [^] (5,552 bytes) 04-19-05 09:18
 Clicks ala Elisp.gif [^] (15,852 bytes) 04-19-05 09:19

04-15-05 18:27   
See 0001077 for an illustration of expected event order
04-19-05 05:49   
See also Mantis 0001037 for other squeak clickstate bugs. I don't have a platform for testing tweak but the clickstate tester here should be applicable or adaptable for your stuff. Ditto the analysis tools.

04-19-05 06:56   
As I tried to educate myself on what double clicks should really mean I came across this beautiful piece of documentation for elisp (emacs lisp).
Its idea of order is somewhat at odds with what I've seen here and in squeak. Still it makes a lot of sense to me and it includes distinctions for double-drag. I like it because it pleases my sense of consistency and completeness.

elisp doc on repeat mouse events:

21.6.7 Repeat Events

If you press the same mouse button more than once in quick succession without moving the mouse, Emacs generates special repeat mouse events for the second and subsequent presses.

The most common repeat events are double-click events. Emacs generates a double-click event when you click a button twice; the event happens when you release the button (as is normal for all click events).

The event type of a double-click event contains the prefix `double-'. Thus, a double click on the second mouse button with meta held down comes to the Lisp program as M-double-mouse-2. If a double-click event has no binding, the binding of the corresponding ordinary click event is used to execute it. Thus, you need not pay attention to the double click feature unless you really want to.

When the user performs a double click, Emacs generates first an ordinary click event, and then a double-click event. Therefore, you must design the command binding of the double click event to assume that the single-click command has already run. It must produce the desired results of a double click, starting from the results of a single click.

This is convenient, if the meaning of a double click somehow "builds on" the meaning of a single click--which is recommended user interface design practice for double clicks.

If you click a button, then press it down again and start moving the mouse with the button held down, then you get a double-drag event when you ultimately release the button. Its event type contains `double-drag' instead of just `drag'. If a double-drag event has no binding, Emacs looks for an alternate binding as if the event were an ordinary drag.

Before the double-click or double-drag event, Emacs generates a double-down event when the user presses the button down for the second time. Its event type contains `double-down' instead of just `down'. If a double-down event has no binding, Emacs looks for an alternate binding as if the event were an ordinary button-down event. If it finds no binding that way either, the double-down event is ignored.

To summarize, when you click a button and then press it again right away, Emacs generates a down event and a click event for the first click, a double-down event when you press the button again, and finally either a double-click or a double-drag event.

If you click a button twice and then press it again, all in quick succession, Emacs generates a triple-down event, followed by either a triple-click or a triple-drag. The event types of these events contain `triple' instead of `double'. If any triple event has no binding, Emacs uses the binding that it would use for the corresponding double event.

If you click a button three or more times and then press it again, the events for the presses beyond the third are all triple events. Emacs does not have separate event types for quadruple, quintuple, etc. events. However, you can look at the event list to find out precisely how many times the button was pressed.

Function: event-click-count event
This function returns the number of consecutive button presses that led up to event. If event is a double-down, double-click or double-drag event, the value is 2. If event is a triple event, the value is 3 or greater. If event is an ordinary mouse event (not a repeat event), the value is 1.

Variable: double-click-fuzz
To generate repeat events, successive mouse button presses must be at approximately the same screen position. The value of double-click-fuzz specifies the maximum number of pixels the mouse may be moved between two successive clicks to make a double-click.

Variable: double-click-time
To generate repeat events, the number of milliseconds between successive button presses must be less than the value of double-click-time. Setting double-click-time to nil disables multi-click detection entirely. Setting it to t removes the time limit; Emacs then detects multi-clicks by position only.
04-19-05 09:22   
Added a couple of graphs to illustrate the difference between bert's version of clicks and elisps version. (These are my interpretations of things so if they are off its due to my misunderstandings but I think I got it right.
04-19-05 12:02   
I like the emacs scheme, and your drawings. However, this issue 0001039 is a bug report, and we should not clutter it up with feature discussion. I filed 0001038 to discuss features such as triple-click.
04-25-05 11:10   

Ok, you may be right.

My thought processes are different than yours and my belief is that the way to fix a bug is to combine all the factors that need to be work towards and find a solution that satisfies all of them. I put this stuff here because it was the bug report and the most urgent and most likely to be attended to.
The solution to this bug seems very much to be deciding exactly what clickstate should be doing and your proposed solution is indeed different from what it was doing. I think it is also different from what squeak does with click state ( I need to go back and look at that again to refresh my memory.)
Also how this bug/issue is resolved will have a direct impact on whether triple click will be easy/possible to implement. So I felt it was important to give that consideration here as well. And I felt what I posted here was germane and relevant.
If I've guessed wrong and posted off topic I appologize. Using mantis is new to all of us. I'm trying to be as helpful as possible and I am still learning.