Rewrite Alt+Right next-element functions as a tree-traversal

[shoogle]

The EngravingItem::nextElement() and EngravingItem::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:

EngravingItem* EngravingItem::nextElement()
{
    // Return first child if there is one.
    for (EngravingItem* child : children()) {
        if (child) {
            return child;
        }
    }
    // Otherwise return next sibling in ancestor element.
    EngravingItem* current = this;
    while (EngravingItem* parent = current->parent()) {
        EngravingItemList siblings = parent->children();
        auto it = siblings.cbegin();
        for (;; ++it) {
            IF_ASSERT_FAILED(it != siblings.cend()) {
                break;
            }
            if (*it == current) {
                ++it;
                break;
            }
        }
        for (; it != siblings.cend(); ++it) {
            if (EngravingItem* sibling = *it) {
                return sibling;
            }
        }
        current = parent;
    }
    return nullptr;
}

EngravingItem* EngravingItem::nextNavigableElement()
{
    for (EngravingItem* next = nextElement(); next; next = next->nextElement()) {
        if (!next->flag(ElementFlag::NOT_SELECTABLE)) {
            return next;
        }
    }
    return nullptr;
}

But which tree should we traverse? There are several possible candidates for the parent() and children() functions.

Navigation Parent	Navigation Children
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.

[shoogle]

Advantages of making this change:

1. Elements that are currently ignored by Alt+Right would now be included:
   • [Accessibility] Tuplets skipped by Alt+Left and Alt+Right #17600
   • [Accessibility] Gradual tempo changes skipped by Alt+Left and Alt+Right #17599
   • Some Text Types Can be Disembodied from a Note/Rest and Made Inaccessible via Next/Previous Element Keyboard Command #16750
2. All future engraving elements would be navigable with Alt+Right automatically.
   • We wouldn't need to remember to add things to the next-element functions.
   • Everything would be automatically included, unless we explicitly exclude it by making it non-selectable.
3. Code would be easier to read, understand, and maintain.

[Leo-Cal]

Hi! I would like to start contributing to MuseScore by tacking this issue. Is this alredy being worked on?

[shoogle]

Hi @Leo-Cal! This is a core issue for accessibility and will set the direction for future development in this area. As such, I'd like to reserve this one for the internal team, but please feel free to tackle other issues, such as the ones on our community projects board. Thanks!

[MarcSabatella]

Timing of this is interesting as I just saw a request from a blind user on the MuseScoreAccessibility mailing list at groups.io to have new commands to allow more direct access to the tree, much as screen readers usually present the accessibility tree of any window or web page and allow direct access to it. This came up in a discussion about having a "next element of same type" command that would allow navigation directly from, say, one tempo marking to the next. it would be nice to design this new tree traversal scheme in a way that could easily support such commands, or even present the accessibility tree directly to screen readers.