1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
//! **Assertion (a): the pane behind a control is still behind it at every
//! window size**, asked of the accessibility tree rather than of the pixels.
//!
//! # What "the settings panel" is in this seat
//!
//! The ball that filed this asked for *the settings panel, reachable from the
//! main screen in a bounded number of gestures at every matrix size*. **This
//! seat has no settings panel** — the window is a notice bar, the roster, the
//! conversation list, the composer and the conversation, and there is no
//! preferences surface anywhere in `crate::ui`. The premise was written from
//! the shape a desktop app usually has.
//!
//! What the assertion is *about* survives that intact: a window has surfaces
//! you navigate to and back from, and the way they break is that the control
//! opening one stops being reachable when the window narrows — the pane is
//! still there, still correct, and nobody can get to it.
//!
//! **The premise has since come true** (bl-4a2c). [`crate::ui::tuning`] is a
//! settings panel by any reading: a place you go to, act in, and come back
//! from, holding what a wall's roles are set to. So the walk covers every
//! covering pane rather than the one — ten of them since bl-d2af — and it is
//! still two gestures each, in and back out, because that bound is what the
//! assertion is, and it is the same bound whether the seat has one such pane or
//! seven.
//!
//! **And the bound is a fact about the SHAPE, so it is asked per shape**
//! (bl-dfda). The narrow layout puts one column on the glass at a time, which
//! is the very thing that makes a pane's control unreachable when a window
//! narrows — so the walk asks for it there: one gesture to the column the
//! control lives on, then the same two. Three per pane, stated, is the
//! assertion; a pane that needed a fourth is the defect it exists to catch.
//!
//! # Why the accessibility tree and not the glass
//!
//! [`crate::test_support::window::click`] aims at painted glyphs, which is the
//! right instrument for *"is this word on the screen"*. It cannot answer *"can
//! this be acted on"*: a run of text that reached the glass may be a label, and
//! a control an operator can reach by keyboard may have no glyph of its own.
//! The accessibility tree is the set of things that ARE controls, which is the
//! set the question is about.
use crate;
use Harness;
use Queryable;
/// **One leg of the walk**: the control to spend, and what has to be there
/// after spending it.
pub
/// **One covering pane, and the column its opening control lives on.**
///
/// The column is what makes the walk answerable in both shapes: in the broad
/// shape every column is on the glass, so it costs nothing to be told; in the
/// narrow shape it is exactly the gesture that has to be spent first.
/// **The ten covered panes this walk visits, in the order it visits them.**
///
/// The tuning pane goes first because both roster-row controls stand the other
/// down while one is open — so a walk that opened the enrollment first would
/// find the tuning control gone and complain about a seat that is behaving
/// exactly as designed. The records pane goes last for the mirror of that
/// reason: its control hangs off the composer, which every covering pane stands
/// down, so it is walked once every roster-row pane has been closed again
/// (bl-2cf7). The decision queue's control hangs off the roster too, above the
/// channels rather than off a row, so it stands and falls with the others and
/// is walked among them (bl-f0ef). The unmaking's control is a third one on the
/// aimed row and is walked among them for the same reason (bl-48fa). The
/// window's own two hang off the roster above the channels beside the queue's,
/// and are walked among them for the same reason (bl-40ec). The login pane's
/// control is a fourth one on the aimed row and is walked among them too
/// (bl-e3c5). The trail's hangs off the roster beside the queue's, its subject
/// being every channel as well (bl-4c48), and the ball pane's beside those two
/// on the same terms — two of its four reads name no workspace (bl-d2af).
const PANES: = ;
/// **The walk, and its length is the bound** — which is a fact about the SHAPE
/// and so is answered per shape (bl-dfda).
///
/// Two legs per pane, one gesture in and one back out. The narrow shape adds
/// exactly one more per pane, and adds it unconditionally rather than only
/// where the column has to change: **go to the column the control lives on,
/// open, close**. That the step is sometimes a click on the column already
/// showing is the point — a bound that varied with where the walk happened to
/// be standing would be a bound nobody could state.
///
/// A leg appearing beyond these is the assertion telling you a pane moved
/// further away than the shape it is in accounts for.
pub
/// Whether anything reachable carries exactly this label.
/// Spend one gesture on the control reading exactly `label`, if there is one.
/// **Walk it, and say what broke.** An empty answer is the assertion holding.
///
/// It stops at the first leg that fails rather than carrying on: once a gesture
/// did not land, every later complaint is about a window that is not in the
/// state the walk assumes, and three consequential complaints hide the one
/// fact.
pub