Check-in [73f04c8063]

Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Editorial fixes in TIP #532 (not finished - numbering still not fully OK)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:73f04c80631f7d23bd9b93850ddb717879ba7b99790df38242b8dd5da79882c9
User & Date: fvogel 2019-01-13 16:27:04
Context
2019-01-13
16:30
One more editorial fix check-in: a36d1b88b0 user: fvogel tags: trunk
16:27
Editorial fixes in TIP #532 (not finished - numbering still not fully OK) check-in: 73f04c8063 user: fvogel tags: trunk
15:48
Update the home page of TIPs check-in: 0683c363e7 user: fvogel tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to tip/532.md.

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
..
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
..
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113

114
115

116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
...
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
# Rationale

The following problems, caused by event ring overflow, have been solved:

1. Sometimes double-clicks with mouse will not be detected, nothing happens although this
event is bound (see test case
[bind-32.2](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6123-6143)).
This problem occurs often in applications[Scidb](http://scidb.sourceforge.net),
because this application is using tooltips heavily, causing a lot of intervening
expose events.

2. Immediately after startup of application [Scidb](http://scidb.sourceforge.net)
(same with applications [Scid](http://scid.sourceforge.net), and
[Scid vs PC](http://scidvspc.sourceforge.net))
it's not possible to open the menu via a shortcut like \<Alt-m\>. This event will be
................................................................................

3. After switching a tab pane in a notebook window the tab is losing the focus sometimes.
This has been observed in applications [Scid](http://scid.sourceforge.net), and
[Scid vs PC](http://scidvspc.sourceforge.net).

Moreover the following issues have been solved:

4. It's possible to bind an event like `\<Quadruple-1\>`, but it's nearly impossible to
trigger this event (with mousepad). Even a triple-click is not so easy. This behavior is
user-unfriendly, and it seems that it is caused by an erroneous implementation.

5. If a statement like `event generate . \<1\>` is executed, and after some time
(\> 500 ms) this statement is executed again, then it's likeky that a double-click event
will be triggered, even if a single-click event is expected, because the triggering
of double-click events has to fit time requirements (due to manual; see test case
[bind-32.4](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6158-6171)).

6. `event generate . \<FocusIn\> -sendevent 1` is not working, the argument of
`sendevent` get lost (test case
[bind-32.6](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6192-6204)).

7. See following code:

		bind . \<Double-1\> { lappend x "Double" }  
		bind . \<1\>\<1\> { lappend x "11" }  
		event generate . \<1\> -x 0 -y 0 -time 0  
		event generate . \<1\> -x 0 -y 0 -time 0
		set x

	This gives the result `11`, but `Double` is expected, because the time (and space)
	constraints for a double click are fulfilled. With other words, the legacy implementation
	is not preferring the most specialized event. But it should, because the manual says
	(`man bind`):

	> If more than one binding matches a particular event and they have the
	> same tag, then the most specific binding is chosen and its script is
	> evaluated.

	And the sequence `\<Double-1\>` is more specific than `\<1\>\<1\>` because of time and
	space requirements (in `\<Double-1\>`). Note that constant `PREFER_MOST_SPECIALIZED_EVENT=1`
	has to set when compiling to enable this new feature.

8. Legacy implementation cannot handle homogeneous equal sequences properly, see this script:

		bind . <1><Control-1> { lappend x "first" }
		bind . <Control-1><1> { lappend x "last" }
		event generate . <Control-1>
		event generate . <Control-1>
................................................................................
		set x
	
	Manual (`man bind`) says:

	> If these tests fail to determine a winner, then the most recently registered
	> sequence is the winner.

	In this script there is no winner, so the latter defined one has to be chosen, and
	revised implementation is doing this.

Legacy code also suffers from causing memory holes, revised implementation is tested
to be memory friendly.

The revised implementation supports an additional syntax for binding motion events
(if constant `SUPPORT_ADDITIONAL_MOTION_SYNTAX=1` is set when compiling). E.g.,
the following bindings

	bind . \<B2-Motion\> { ... }  
	bind . \<B1-B2-Motion\> { ... }

can be expressed in a different way:


  	bind . \<Motion-2\> { ... }  
  	bind . \<Motion-1-2\> { ... }


The additional syntax is easier to remember, because button press/release events will also
be expressed in the latter form, for example `bind . \<ButtonPress-1\>`. The former
syntax (`\<B2-Motion\>`) form will still be supported.

# Specification

The whole handling in file `general/tkBind.c` has been re-implemented. This implementation
is passing all test cases in `tests/bind.test`. Note that legacy implementation is failing
in some (of the new) test cases.

Case (4): Legacy implementation is computing the time difference of nth click with fst click,
and tests whether it is less than 500 ms. But this seems to be an implementation bug. Revised
implementation computes the difference of nth and (n+1)th click. This behavior also conforms
better to the behavior of other toolkits. With new implementation the use of quadruple clicks
(and triple clicks) is unproblematic. See also test case
[bind-32.6](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6172-6191).

Case (5) is only a minor bug, and there exists a work-around. But the author decided to
eliminate this design bug, with revised implementation option **-time** is recognizing new
special value **current**, and is using the current event time in this case. This extension
................................................................................

For the fix of case (6) the author decided that non-zero values (given with option
**-send_event**) will be converted to **1**. This is conform to the manual, see
`man bind` (search for **Sendevent**), see also lines 3287ff in legacy file
[generic/tkBind.c](http://core.tcl.tk/tk/artifact/e41f45f7f6ac3447?ln=4178-4203).

The fix of (7) is not fully backwards compatible. But in the author's opinion this is not
a real problem, nobody is using sequences like `\<1\>\<1\>`, it is not expected that
applications have to be adjusted.

Fix of (8) is correcting a major bug, see test case
[bind-33.13](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6550-6566).

# Implementation








|







 







|



|
|




|
|




|
|
|
|











|
|
|







 







|









|
|



>
|
|
>


|
|







|

|







 







|







28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
..
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
..
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
...
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
# Rationale

The following problems, caused by event ring overflow, have been solved:

1. Sometimes double-clicks with mouse will not be detected, nothing happens although this
event is bound (see test case
[bind-32.2](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6123-6143)).
This problem occurs often in application [Scidb](http://scidb.sourceforge.net),
because this application is using tooltips heavily, causing a lot of intervening
expose events.

2. Immediately after startup of application [Scidb](http://scidb.sourceforge.net)
(same with applications [Scid](http://scid.sourceforge.net), and
[Scid vs PC](http://scidvspc.sourceforge.net))
it's not possible to open the menu via a shortcut like \<Alt-m\>. This event will be
................................................................................

3. After switching a tab pane in a notebook window the tab is losing the focus sometimes.
This has been observed in applications [Scid](http://scid.sourceforge.net), and
[Scid vs PC](http://scidvspc.sourceforge.net).

Moreover the following issues have been solved:

4. It's possible to bind an event like <code>\<Quadruple-1\></code>, but it's nearly impossible to
trigger this event (with mousepad). Even a triple-click is not so easy. This behavior is
user-unfriendly, and it seems that it is caused by an erroneous implementation.

5. If a statement like <code>event generate . \<1\></code> is executed, and after some time
(\> 500 ms) this statement is executed again, then it's likely that a double-click event
will be triggered, even if a single-click event is expected, because the triggering
of double-click events has to fit time requirements (due to manual; see test case
[bind-32.4](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6158-6171)).

6. <code>event generate . \<FocusIn\> -sendevent 1</code> is not working, the argument of
<code>sendevent</code> get lost (test case
[bind-32.6](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6192-6204)).

7. See following code:

		bind . <Double-1> { lappend x "Double" }  
		bind . <1><1> { lappend x "11" }  
		event generate . <1> -x 0 -y 0 -time 0  
		event generate . <1> -x 0 -y 0 -time 0
		set x

	This gives the result `11`, but `Double` is expected, because the time (and space)
	constraints for a double click are fulfilled. With other words, the legacy implementation
	is not preferring the most specialized event. But it should, because the manual says
	(`man bind`):

	> If more than one binding matches a particular event and they have the
	> same tag, then the most specific binding is chosen and its script is
	> evaluated.

	And the sequence <code>\<Double-1\></code> is more specific than <code>\<1\>\<1\></code> because of time and
	space requirements (in <code>\<Double-1\></code>). Note that constant `PREFER_MOST_SPECIALIZED_EVENT=1`
	has to be set when compiling to enable this new feature.

8. Legacy implementation cannot handle homogeneous equal sequences properly, see this script:

		bind . <1><Control-1> { lappend x "first" }
		bind . <Control-1><1> { lappend x "last" }
		event generate . <Control-1>
		event generate . <Control-1>
................................................................................
		set x
	
	Manual (`man bind`) says:

	> If these tests fail to determine a winner, then the most recently registered
	> sequence is the winner.

	In this script there is no winner, so the later defined one has to be chosen, and
	revised implementation is doing this.

Legacy code also suffers from causing memory holes, revised implementation is tested
to be memory friendly.

The revised implementation supports an additional syntax for binding motion events
(if constant `SUPPORT_ADDITIONAL_MOTION_SYNTAX=1` is set when compiling). E.g.,
the following bindings

	bind . <B2-Motion> { ... }  
	bind . <B1-B2-Motion> { ... }

can be expressed in a different way:

<code>
  	bind . \<Motion-2> { ... }  
  	bind . \<Motion-1-2> { ... }
</code>

The additional syntax is easier to remember, because button press/release events will also
be expressed in the latter form, for example <code>bind . \<ButtonPress-1></code>. The former
syntax (<code>\<B2-Motion></code>) form will still be supported.

# Specification

The whole handling in file `general/tkBind.c` has been re-implemented. This implementation
is passing all test cases in `tests/bind.test`. Note that legacy implementation is failing
in some (of the new) test cases.

Case (4): Legacy implementation is computing the time difference of nth click with first click,
and tests whether it is less than 500 ms. But this seems to be an implementation bug. Revised
implementation computes the difference of nth and (n+1)th clicks. This behavior also conforms
better to the behavior of other toolkits. With new implementation the use of quadruple clicks
(and triple clicks) is unproblematic. See also test case
[bind-32.6](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6172-6191).

Case (5) is only a minor bug, and there exists a work-around. But the author decided to
eliminate this design bug, with revised implementation option **-time** is recognizing new
special value **current**, and is using the current event time in this case. This extension
................................................................................

For the fix of case (6) the author decided that non-zero values (given with option
**-send_event**) will be converted to **1**. This is conform to the manual, see
`man bind` (search for **Sendevent**), see also lines 3287ff in legacy file
[generic/tkBind.c](http://core.tcl.tk/tk/artifact/e41f45f7f6ac3447?ln=4178-4203).

The fix of (7) is not fully backwards compatible. But in the author's opinion this is not
a real problem, nobody is using sequences like <code>\<1\>\<1\></code>, it is not expected that
applications have to be adjusted.

Fix of (8) is correcting a major bug, see test case
[bind-33.13](https://core.tcl-lang.org/tk/artifact/6377cb0d762b7261?ln=6550-6566).

# Implementation