Refactor and cleanup score tree functions #30899
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prompted from this consideration, I took a closer look at the functions in scoretree.cpp, namely
scanParentandscanChildren. As far as I could see, they were introduced for some score tree visualization feature back in version 3, but as far as I'm aware that feature doesn't exist in version 4. Everything about this is quite weird, because the parent and child relationships sometimes don't follow the true hierarchy of our model (ChordRests collect spanners among their children, Spanner collect SpannerSegment even though the parent of a SpannerSegment is always the System, scanParent sometimes returns an item that isn't the parent...). Most of these functions are either stale or are a copy of the correspondingscanElementsmethod. The "source of truth" is obviouslyscanElements, cause that's what we use to determine what is drawn on screen.This PR:
scanParentandscanChildrenfunctions, moving all the relevant functionality toscanElementsEngravingObject::getChildren, which collects the list of children usingscanElementsscanElementsusingstd::functioninstead of the old C-style function pointers. This makes everything nicer, especially avoiding all thevoid*pointers.scanElementsall the logic that had to do with showing or not showing the item on screen. The whole point of something likescanElementis that it doesn't know whatfuncwill do, so putting that logic inscanElementis an antipattern. Deciding whether or not to collect an element should be decided insidefuncitself.