Skip to content

Expose a numeric range value and radio selection items - #354

Open
rezabakhshilaktasaraei wants to merge 7 commits into
desktop-app:masterfrom
rezabakhshilaktasaraei:slider-value-interface
Open

Expose a numeric range value and radio selection items#354
rezabakhshilaktasaraei wants to merge 7 commits into
desktop-app:masterfrom
rezabakhshilaktasaraei:slider-value-interface

Conversation

@rezabakhshilaktasaraei

Copy link
Copy Markdown
Contributor

Two additions the value-picking sliders in tdesktop need:

  • RpWidget can report a numeric range (accessibilityValueRange) and the accessible wrapper then exposes QAccessibleValueInterface, which UI Automation maps to the RangeValue pattern. Value change events keep carrying the textual value - that is the one a screen reader announces and reads the value back from.
  • RadioButton is accepted as a selection item role next to ListItem and PageTab, so a group of painted radio buttons resolves its checked item through the selection interface.

Built on top of #348 - only the last two commits are new.

A painted list had no way to tell a screen reader that a row became the
current one, or stopped being: the Windows bridge reads only the checked
flag out of a state change and ignores the selected one, so the folder
tabs went silent where the folders that are real widgets say "selected" -
SideBarButton raises the selection event itself.
A strip of real tab buttons (the forum topic tabs) is named tabs in the
UI, so a screen reader should call its items tabs as well. setIsPageTab
gives a button the PageTab role, and the selection interface of the
container accepts those items alongside list items - the Windows bridge
grants the Selection patterns by the interface, not the role, so a
PageTabList container keeps working the same way a List does.
A container with painted children holds real keyboard focus itself
while the browse position moves between them, so forwarding container
focus to the selected item would announce the current item when the
screen reader asked for a merely browsed one. A child reporting focus
now wins; the selection forwarding stays as the fallback.
The selected state and the selection events of SideBarButton were
gated on the list item role, so switching the folders sidebar to tabs
silenced them. The sidebar is the only user of this widget and it is
tabs now, so the gate simply follows the role along.
A menu asked for from the keyboard opens at the mouse cursor at every
call site, which may sit nowhere near the control or outside the
window altogether - and the position Qt puts into the keyboard event
is synthesized from the input method rect, which plain controls leave
empty. The helper anchors a keyboard-invoked menu on the control (or
on a painted element inside it) and keeps the cursor position for a
mouse-invoked one, so call sites can adopt the policy with one line.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant