Rewrite Alt+Right next-element functions as a tree-traversal #23890
Labels
accessibility
Issues related to accessibility
internal
Issues for the internal team
P2
Priority: Medium
Tech debt
The
EngravingItem::nextElement()
andEngravingItem::previousElement()
virtual functions define the order in which elements are visited by the Alt+Right and Alt+Left navigation shortcuts.The way these functions are currently written, they must be overridden by every
EngravingItem
subclass to determine what comes next in the sequence. However, there is no guarantee that the sequence is consistent, correct, or complete. Ideally, all interactive elements should be included, while all non-interactive elements (e.g.Page
,System
, etc.) should be excluded.These functions could be greatly simplified by rewriting them as a tree-traversal, which could look something like this:
But which tree should we traverse? There are several possible candidates for the
parent()
andchildren()
functions.EngravingObject::parent()
EngravingObject::explicitParent()
EngravingObject::children()
EngravingObject::scanParent()
EngravingObject::scanChildren()
EngravingItem::parentItem(false /*explicit*/)
EngravingItem::parentItem(true /*explicit*/)
EngravingItem::childrenItems()
AccessibleItem::accessibleParent()
AccessibleItem::accessibleChild(i)
AccessibleItem::accessibleChildCount()
We'll need to use the one that gives the closest match to the current next-element sequence.
We may still need to override
nextElement
in a few subclasses, for example, to ensure that navigation stays in the current staff rather than going up and down the segments.The text was updated successfully, but these errors were encountered: