Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MU4] Move ScoreAccessibility::barbeat(Element) to Element::barbeat() #5096

Closed
wants to merge 1 commit into from

Conversation

mirabilos
Copy link
Contributor

No caller passes a nil argument, and an Element can now describe its own position, which is useful when generating debugging output.

A function QString Element::accessibleBarbeat() is also added, based on ScoreAccessibility::currentInfoChanged() for elements.

Both methods can be used on const elements, which, again, is important for debugging output.

Finally, the accessibility strings generated by ScoreAccessibility::currentInfoChanged() were inconsistent; now, the status line text uses colons and semicolons consistently, and both it and the score->setAccessibleInfo() argument have a consistent amount of spaces added (before, sometimes there were two or even (worse) no space where one was expected).

As a downside, since ScoreAccessibility::currentInfoChanged() needs to calculate the information twice, and also for ranges and spanners, there is a tiny amount of code duplication (as also the order of execution differs) between it and the new Element::accessibleBarbeat(). This could be fixed by refactoring more (introduce accessibleBarbeat() to spanners and range selections and make it return an std::pair<QString, QString> providing both information) but I’ve decided to keep it simple for now.

Use case: I have a code path in a local patch to the synthesiser in which I wish to output information (pitch, voice, beat, measure, stave) for a const Note*. I imagine others have the same problem.

No caller passes a nil argument, and an Element can now describe
its own position, which is useful when generating debugging output.

A function QString Element::accessibleBarbeat() is also added,
based on ScoreAccessibility::currentInfoChanged() for elements.

Both methods can be used on const elements, which, again, is
important for debugging output.

Finally, the accessibility strings generated by
ScoreAccessibility::currentInfoChanged() were inconsistent;
now, the status line text uses colons and semicolons consistently,
and both it and the score->setAccessibleInfo() argument have
a consistent amount of spaces added (before, sometimes there
were two or even (worse) no space where one was expected).

As a downside, since ScoreAccessibility::currentInfoChanged()
needs to calculate the information twice, and also for ranges
and spanners, there is a tiny amount of code duplication (as
also the order of execution differs) between it and the new
Element::accessibleBarbeat(). This could be fixed by refactoring
more (introduce accessibleBarbeat() to spanners and range
selections and make it return an std::pair<QString, QString>
providing both information) but I’ve decided to keep it simple
for now.
@dmitrio95
Copy link
Contributor

Actually it looks like Element is not the best place for a method like this. It could probably be better to make a separate class for constructing accessible info for elements, or at least make methods like this virtual and override them in descendant classes. Both these solutions might go beyond the scope of this PR though.

@mirabilos
Copy link
Contributor Author

mirabilos commented Mar 12, 2020 via email

@MarcSabatella
Copy link
Contributor

I do think there is room for cleaning up how this is handled, but I'm not terribly crazy about having Element construct this information itself. Why not just adapt the existing barBeat to be a publicly-visible static member function of ScoreAccessibility? Or perhaps a general utility function that you pass in a tick to.

In any case, it also needs rebasing to account for the actual changes in how the info is presented. @shoogle has also been investigating other architectural changes, not sure how that is going or if that would conflict.

@shoogle
Copy link
Contributor

shoogle commented Mar 12, 2020

My architectural changes have been put on hold for the time being (see GSoC idea Tree model for libmscore) so feel free to make more straightforward improvements in the meantime.

@mirabilos
Copy link
Contributor Author

mirabilos commented Mar 12, 2020 via email

@MarcSabatella
Copy link
Contributor

OK, although it might help to understand why. To me, it "feels" like libmscore shoudl be able to do things like tell you the tick of an element, maybe even return an integer for measure number and fraction or qreal for beat. But mscore is more appropriate for code that turns that into any sort of English (or other language) descriptive phrase. After all, it's UI-ish.

If there is some good reason I'm not seeing for having it in libmscore, though, then maybe have it be a static member of Score instead.

@mirabilos
Copy link
Contributor Author

mirabilos commented Mar 12, 2020 via email

@MarcSabatella
Copy link
Contributor

I'm not understanding what debugging has to to do with it, debuggers are just as capable of accessing mscore code as libmscore code. Sounds like you have some sort of real unusual special project going on here, but we don't have the context needed to understand its unique requirements.

@mirabilos
Copy link
Contributor Author

mirabilos commented Mar 13, 2020 via email

@igorkorsukov igorkorsukov changed the title Move ScoreAccessibility::barbeat(Element) to Element::barbeat() [MU4] Move ScoreAccessibility::barbeat(Element) to Element::barbeat() Feb 5, 2021
@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Sep 6, 2021

Rebase needed. Maybe on top of 3.x?

@mirabilos
Copy link
Contributor Author

mirabilos commented Sep 6, 2021 via email

@igorkorsukov igorkorsukov added the archived PRs that have gone stale but could potentially be revived in the future label Sep 9, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 13, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 13, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 14, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 14, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 16, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 17, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 17, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 17, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 17, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 20, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 21, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 22, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 23, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 24, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 26, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Sep 29, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Oct 3, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Dec 7, 2021
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request May 12, 2022
Jojo-Schmitz pushed a commit to Jojo-Schmitz/MuseScore that referenced this pull request Mar 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archived PRs that have gone stale but could potentially be revived in the future
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants