Skip to content

moveElementSelection: only start editing when selected element wants it #29287

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

Merged
merged 3 commits into from
Aug 19, 2025

Conversation

cbjeukendrup
Copy link
Member

Since b5dc600, it would cause text editing to be started, since Dynamic::defaultGrip (==EngravingItem::defaultGrip) (intentionally) returns NO_GRIP.

Resolves: #29286

(The change in NotationInteraction::startEditGrip is not great, but I don't see a better way at the moment)

m_editData.element->startEdit(m_editData);
if (grip == engraving::Grip::NO_GRIP && m_editData.element->isDynamic()) {
// Ensure we don't start text edit mode. See also Dynamic::startEdit.
m_editData.element->EngravingItem::startEdit(m_editData);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding a bool flag to EditData that will indicate whether we should start the text edit mode or not?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's similar to what we had before b5dc600, though... but maybe we should do that anyway. @mike-spa what are your thoughts about this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a completely different fix, following advice from Michele on Slack.

Since musescore@b5dc600, it would cause text editing to be started, since `Dynamic::defaultGrip` (==`EngravingItem::defaultGrip`) (intentionally) returns NO_GRIP.

Resolves: musescore#29286
This reverts commit fb1fca1.

That commit was not a correct fix. Since `NotationInteraction::drawGripPoints` already contains a special case for dynamics, we should not call any sort of `startEditElement` method at all when selecting a dynamic, respecting Dynamic::needStartEditingAfterSelecting.
- Check toEl->needStartEditingAfterSelecting()
- Use `startEditElement` rather than `startEditGrip`
- Improve `startEditElement` to be appropriate for all elements
@cbjeukendrup cbjeukendrup force-pushed the dynamic_starteditgrip branch from c3ad921 to 26bdd2a Compare August 18, 2025 12:19
@cbjeukendrup cbjeukendrup changed the title Fix NotationInteraction::startEditGrip for dynamics moveElementSelection: only start editing when selected element wants it Aug 18, 2025
@zacjansheski
Copy link
Contributor

Tested on MacOS 15, Windows 11, Ubuntu 22.04.3. Approved

#29286 FIXED

@cbjeukendrup cbjeukendrup merged commit df2ae7f into musescore:master Aug 19, 2025
13 checks passed
@cbjeukendrup cbjeukendrup deleted the dynamic_starteditgrip branch August 19, 2025 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When navigating score with option+arrow , when a dynamic is reached it enters edit mode
4 participants