You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gui: a press puts the keyboard on a switch, a frozen control answers no key
Four findings of an outside review of the pull request, each checked
against the toolkit's source before anything was changed, and one more
found beside them.
A press on a switch - the square and the segmented one - now puts the
keyboard on it quietly, and the first key drawn on it turns the ring on: the
rule PointerFocus has stated since the menus, which the Chooser followed and
the two controls of the rework did not. The desktop driver unfocuses whatever
had the keyboard on a press and leaves focusing to the widget
(internal/driver/glfw/window.go, mouseClicked); the toolkit's own Check and
radio item focus themselves in Tapped, and ours did not, so after a click
the keyboard was nowhere - the next Space flipped nothing and the next Tab
started from the top of the screen. The review said the keyboard stayed on
the previous control, which the driver does not do, and drew the right
conclusion from the wrong mechanism. The guard that promised "a press moves
the keyboard without drawing its mark" asked only about the mark, so a
control that took the keyboard nowhere passed it. It asks both now.
A frozen control answers no key. The focus manager asks Disabled only when
it moves the focus, and the driver hands every key to whatever is focused,
so a segmented switch that had the keyboard when a run began went on moving
its choice under a form drawn as frozen. The review named the switch. The
menu does the same through the toolkit's Select.TypedKey, which asks nothing
either, and is stopped in the same place.
One press of the space bar flips a switch once. Toggle.TypedRune answered the
space character as Button.TypedRune did, so a press flipped the switch twice
and left it where it was, which reads as a switch that ignores space. Found
by reading the control beside the one the review named.
An ownWork exemption that no build spends is red, as a registry entry that
no build matches already was: a key for a file that has gone would exempt
whatever landed at that path next.
The catalogue no longer writes its window size down as the size the
ordinary window opens at. The comment beside it said nothing about it was
remembered, and the close callback two lines below remembered it. Behind
cgo, like the rest of the remembering, so no guard reaches it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments