Repository navigation
v0.23.0
Added
Core
AccessNodeBuilder::push_list_child,push_list_item_childand
push_heading_childpush aRole::List, aRole::ListItem(with its
level and position) and aRole::Headingunder a parent of the caller's
choosing, keyed by the newSyntheticKind::RichTextListand
SyntheticKind::RichTextListItem. AmatchoverSyntheticKindneeds
the two new arms.TextSurface::accepts(StandardEdit)says whether the focused text
widget takes Cut, Copy, Paste, Undo or the others at all in its current
mode: a forward-only editor takes a paste and refuses a cut, which
is_read_onlycannot say. A host routing Edit commands to the focused
surface greys its rows by it. It has a default, so an implementor written
before it keeps compiling.
Widgets
RichTextEditor::can_insert_line_breakand
EditorHandle::can_insert_line_breaksay whetherinsert_line_break
would insert now: not where the break would go into a table cell or a code
block. A menu
row for it can grey itself out where it would do nothing. Like the call,
they leave the command filter to the host.
Changed
Core
TextRunSourcehas a new public field,spoken_as, set with
TextRunSource::speak_as: a character a reader hears as other text, such
as an inline image's U+FFFC heard as its description, still one character.
Code that builds aTextRunSourcewith a struct literal needs the field.
Fixed
Widgets
- A
RichTextEditor's context menu and touch selection toolbar offer no
Paste when its command filter refuses one. An editor built editable and
switched toCommandFilter::ReadOnlykept its Paste and Paste Unformatted
rows, and they wrote into it. - A Cut, Paste or Undo a host routes to a
RichTextEditorobeys its
command filter. Routed throughTextSurface(ctx.text_surfaces()),
Ctrl+X underCommandFilter::ForwardOnlytook the selected text away, and
Ctrl+X and Ctrl+V wrote into a read-only editor. The surface's commands now
do what the editor's keys do; the handle's owncutandpastestill
write, for a host acting on its own account. - Under a forward-only filter, a line break over a selection reaching into a
code block or a table cell no longer lands there. Shift+Enter and
insert_line_breakjudged the place by the caret, and the break goes in
after the selection. - A screen reader gets a
RichTextEditor's paragraphs apart. The text
it reads had no character between two paragraphs, so the end of one and
the start of the next were one offset: End at the end of a paragraph read
the next one's first letter, Right across the break was silent, a word or a
paragraph ran on into the next one, and Enter added nothing a reader heard.
Each paragraph now ends with its line break, as AccessKit reads a
paragraph's end. The same holds in the read-only viewer and in table cells. - An inline image or footnote marker in a
RichTextEditoris read in its
place, once, as its description. It was read after its paragraph, and
counted as a character the document does not have. - A screen reader that moves the caret in a
RichTextEditorputs it where
it asked after an accented letter or any other character longer than a
byte. It landed one place further for each such character before it. - A caret on a table's own positions is reported to a screen reader.
Right from the paragraph before a table stops twice before the first cell,
and a reader was told of no caret there; it is told the caret is at the
first cell. - A screen reader gets a
RichTextEditor's lists as lists. Each item's
line starts with its marker as it is painted, its bullet, its number or
its task box, which a reader steps over in one move and the caret never
stops inside. Each list is a list node and each item an item node with its
level, its position and the list's size, and a nested list is inside the
item it follows. Items were read as plain paragraphs, with no marker and
no depth. In a table cell an item reads its marker and has no node of its
own, as a heading there has none. - A heading that opens a blockquote in a
RichTextEditoris read in its
place, inside the quote. It was read after the quote's other text.
Full Changelog: v0.22.0...v0.23.0