Fix #297426: The playback cursor is not repositioned when selecting items other than notes, rests or measures

[Spire42]

Resolves: #297426

Improved the functionality of the playhead (a.k.a. the playback cursor) so that whenever the user selects an element, the playhead is automatically repositioned to the element's time position. Previously, this worked only for noteheads and rests, but it now works for note stems, beams, augmentation dots, accidentals, ties, slurs, articulations, time signatures, key signatures, clefs, tempo changes, dynamics, lines, barlines, breaks, spacers, measure numbers, text, and so on.

Special cases handled:

• Barlines. The playhead is moved to the start of the measure to the right of the barline, unless it's the last barline in either the entire score or the system, in which case the playhead is moved to the start of the measure to the left of the barline.

• Brackets always have a time position of zero, so the playhead is moved to the start of the first measure in the system that the bracket belongs to.

• Instrument names always have a time position of zero, so the playhead is moved to the start of the first measure in the system that the instrument name belongs to.

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
• I created the test (mtest, vtest, script test) to verify the changes I made

[dmitrio95]

Added some minor comments, but the overall solution seems really good to me.

[igorkorsukov]

I believe that determining where to play is not the responsibility of these elements, it is external logic, application level logic rather than domain model (as opposed to getting a tick, for example)

[igorkorsukov]

Having a separate helper class

This is not a class helper, this is a class service that fulfills its responsibility :)

[igorkorsukov]

if you think the logic from where to play is the level of the domain model (and not the application level), then your solution is excellent

[Spire42]

I believe that determining where to play is not the responsibility of these elements, it is external logic, application level logic rather than domain model (as opposed to getting a tick, for example)

We fundamentally disagree on this. If you have a look at the code for the various tick() and rtick() implementations (which in some cases reach out way beyond the scope of the individual element in question), you might change your mind.

[igorkorsukov]

Thanks. I ask you to write comments in the base class that each tick method returns (what is tick, rtick and playTick, when and for what each method needs to be used)

[Spire42]

I ask you to write comments in the base class that each tick method returns (what is tick, rtick and playTick, when and for what each method needs to be used)

I completely agree with you that these three member functions of Element need documentation. However, I also see that of the existing 114 member functions in Element, only around 20 of them have any documentation at all, and what little documentation exists is mostly cryptic and not very helpful.

There has been some talk recently in the Developers Chat of an initiative to write comprehensive Doxygen-style documentation for the entire MuseScore codebase, possibly as a GSoC project. I think that would be a great idea.

In any case, I think writing documentation should be considered an issue on its own, separate from a small fix like this.

[igorkorsukov]

only around 20 of them have any documentation at all, and what little documentation exists is mostly cryptic and not very helpful.

these three functions especially need documentation, because they are all similar, it is not obvious what their difference is.

I personally am not a adherent of documenting everything, I believe in self-documenting code (I try to write code like this). I believe that documentation needs something that is not obvious. Although at the same time I write a lot of comments myself :) (you can see it in my PR)
But perhaps in a large project with a lot of different people, we need to document everywhere.

[Spire42]

OK. I will document the one function I added, but I have to leave the other two alone for now, firstly because they aren't related to this PR, and secondly because I didn't write those functions and I'm not confident that I fully understand them well enough to explain precisely what they're meant to be used for — especially rtick().

[Spire42]

Done.