AccessKit NodeId scheme

[DataTriny]

Feature Description

AccessKit NodeId is a newtype over u64. The current scheme for Slint is as follows:

• Component ID: upper 32 bits
• Item Index: lower 32 bits

Where Component ID is an increasing u32 mapped to an ItemTree pointer and Item Index is just the index of a given item in its tree.

To address #2895 we need to reserve space for AccessKit nodes that don't map to any construction in Slint, the text runs.

@tronical suggested in AccessKit/accesskit#655 (comment) that Slint could just host newly introduced graft nodes and let parley provide subtrees for each block of text. This is unpractical as nodes cannot reference other nodes across subtrees. If text inputs are in the root tree then they cannot reference text runs in the subtree for text selection. If text inputs are also part of the subtree, then we won't ever be able to support "labelled by"/"described by" relationships for these element (I know Slint currently doesn't allow this but this is a common pattern, especially for form inputs). Subtrees are designed to host semantically unrelated fragments of the UI, like a web view or a rich document editor, not for small widgets like text inputs.

Given this:

• How many text runs should we consider? Raw text needs one text run per line up to 256 characters. Rich text needs one text run for each span (think different text style, font, color...)
• Why do item indices need to be an u32? Since they have to be declared explicitly and cannot repeat, this seem massively overkill to me.
• How many components IDs are needed in practice? Components can be repeated but some of them are also temporary.

In my opinion, u16 would already be quite large for item indices, 24 bits would be enough to address text runs for practically every text inputs and 24 bits should be fine to map components for reasonably large UIs.

Any thoughts? I am willing to submit a pull request once we land on a decision.

Product Impact

Part of the NLNet funded project iOS Support for AccessKit

[tronical]

Thanks for bringing this up. I'm inclined to agree that the item index could be u16. With repeaters and large list views., 24 bits for the component seems reasonable.

Large text could be an issue. The first divider will be a paragraph/block of text. Like a line of text with explicit paragraph separator or newline in ascii. Within a paragraph text will be broken into lines and spans.

A text editor could easily display a file with a few hundred thousand lines. Likely each line will be only one span then.

A large html document, such as a single page web spec (or converted to markdown) may be difficult to squeeze into 24 bits.

Maybe I'm off on the order of magnitude?

[DataTriny]

It also look too small to me, but Chromium (which represents rich text and documents roughly the same way as AccessKit) uses u32 for its entire node ID space.

Is it expected for Slint to provide an HTML viewing component? If it will wrap Servo or recommend users use Servo directly then AccessKit subtrees will be an option once we figure out the API for it. I think you'd need a pretty big Markdown document to underflow the 24 bits. Even then, a dedicated Markdown component that uses an AccessKit subtree under the hood is an option.

[DataTriny]

To put things into perspective: in the context of a text editor and with a 24 bit addressing space, we can fit 500 000 lines with 32 spans of text each.