accesskit::NodeClassSet

[dhardy]

I feel like I don't properly understand the purpose of this feature from the documentation.

• "Each node has a class which is created by NodeBuilder,": does this imply that each node has a unique class? This appears to be a contradiction to the meaning of "class".
• "Once a class is added to a class set, it currently remains in that set for the life of that set, whether or not any nodes are still using the class." Does this imply that a node's role, supported actions etc. cannot change? Or does the node's class change in this case?
• What if multiple nodes are created with the same "class set" but different actions?
• Why not simplify and specify role / action / ... only through an explicit class, instead of inferring "class set" properties from Node definitions?

[mwcampbell]

On the first point, maybe the documentation could be clearer. All nodes that are built with the same class set and have the same role, actions, and set of properties (i.e. which properties are set, not the actual values of those properties) have the same class.

Node classes are a way of optimizing memory usage. They're not visible to the platform adapters.

The lcass is an attribute of a given version of a node. So for the same node ID, it's fine for the class to change from one tree update to the next.

Nodes with different actions belong to different classes. But again, this doesn't matter to the platform adapters.

I could have made the node classes completely invisible, but then AccessKit would force the usage of a global data structure behind a mutex. That won't be an option when we eventually add no-std support, and in any case, it didn't seem appropriate for a library targeting a systems language like Rust to impose such a restriction. Many (most?) GUI toolkits will build all their nodes on one thread, so it's desirable for them to use a single NodeClassSet that's not behind a mutex. In practice, all you really have to do is create a NodeClassSet, always pass it to NodeBuilder::build, and otherwise treat node classes as an internal implementation detail that doesn't constrain what you can do.

Then again, for greater efficiency, we could more fully expose node classes, let you create the classes you need, then let you explicitly create nodes with those classes. Looking up a class in the set from the role, actions, and property set does add some performance cost. I had already thought about making this more explicit, but hadn't prioritized it yet.

[dhardy]

So the purpose of NodeClassSet is just to provide AccessKit somewhere to cache node-specific data? Then shouldn't it be called NodeCache and remove everything about classes from the docs?

Alternatively users could construct a static or singleton NodeClass for each widget type, then pass a (const) ref when building the Node. That avoids threading issues and avoids needing to re-specify all actions when e.g. a slider's value changes. If I understand the purpose correctly..