Here's the section I wrote for the ARCHITECTURE.md PR.
Sub-trees
An app's accessibility tree can be composed of several subtrees.
The idea behind subtrees is to allow different actors to produce accessibility trees without coordinating (for example, because they're separate processes in a browser), and let the main application submit them to the adapters, which take care of combining them.
The main way this separation manifests is in namespacing: each subtree can pick whatever NodeIds it wants without worrying about colliding with other subtree's NodeIds.
NodeId(123) in one subtree and NodeId(123) in another subtree refer to completely different nodes
Subtrees are composed through "graft nodes", Node instances with a "tree_id" property set to the id of the subtree.
Each sub-tree has to be submitted to the adapter with a separate TreeUpdate. When presented to the platform's accessibility APIs, the sub trees will be stitched together and submitted as a single accessibility tree.
I think we should have something like this section somewhere in the crate doc, so that doc items can link to it.
An obvious place to put that section would be on the TreeId type, but it can go anywhere as long as rustdoc can link to it and it stays updated.
Here's the section I wrote for the ARCHITECTURE.md PR.
I think we should have something like this section somewhere in the crate doc, so that doc items can link to it.
An obvious place to put that section would be on the
TreeIdtype, but it can go anywhere as long as rustdoc can link to it and it stays updated.