[MU4 Issue] Shorcut bold and Italic issue text issue

[Gai-Luron]

Describe the bug
Ctrl+B, Ctrl+I won't work in text for bold.

To Reproduce
Steps to reproduce the behavior:

1. Add a text
2. Go inedit mode
3. Select all the text
4. Ctrl + B do Nothing, Ctrl+I do Nothing
5. Reassign Ctrl+B in sorcut even if already set.
6. Now Work

For italic, Ctrl+I even assigned to

Re assign to italic, no work
Remove from

Now Ctrl+I Work for italic
Edit : Side effect
Ctrl+I ( previous mode ) now can't delete Measure at end of Score

Platform information
OS: Windows 10 Version 2009, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223160409, revision: github-musescore-musescore-b6a6b23
French keyboard

[Tantacrul]

Yes, the commands are double-assigned for two different actions. We should make these text formatting options the default.

[iwoithe]

Yes, the commands are double-assigned for two different actions. We should make these text formatting options the default.

@Tantacrul What are the desired new shortcuts for Insert one measure at end of score and Note Input: toggle 'insert' mode? I will update the shortcuts once I know. 🙂

---

Slightly off-topic, but it appears that the bold and italics shortcuts only works in the text editing mode. Should the behaviour be the same as the respective buttons in the inspector?

Screen Recording

Specifically note how I am pressing Ctrl+B (look in the terminal for when I do that) and nothing happens unless I am in the text editing mode.

mu-14496-off-topic.mp4

[MarcSabatella]

The Ctrl+I command for toggle insert mode is completely broken and has been for years. It doesn't actually toggle insert mode at all; it simply disabled other commands and introduces score corruption. That commands should either be fixed or removed. See #11844

Ctrl+B in normal mode remains the long-standing shortcut for appending bars to your score. I'm not clear on if changing that to apply bold in normal mode is being proposed, but FWIW, I don't think that would be advisable. There are any number of things that work differently while editing text versus when not (pressing "B" on its own for instance, or Space, or using the cursor keys), so consistency as an end in itself doesn't strike me as a powerful enough reason to change such a commonly used shortcut to perform a relatively uncommon action.

[Tantacrul]

I think we should specify a rule (hidden from the user) that when text is selected, CTRL+B should make it bold. In all other cases, it defaults to the append bars action. This should not be exposed to the user. If they change the shortcut for CTRL+B to something else, it will still work to make selected text bold (and while editing text too)

We have the necessary system for assigning key bindings to a 'hierarchy' of purposes. @shoogle @cbjeukendrup and @igorkorsukov know more about this from a technical POV.

[MarcSabatella]

That's reasonable, and certainly doable. Although I don't think the hierarchy really allows for that degree of granularity. As was also the case in MU3, you can have a given shortcut assigned to different commands in different modes (e.g., text edit vs normal) but some small hacks are still required to do anything more context-sensitive than that - different behaviors depending on what is selected.

For instance, I mentioned the cursor keys, and even within normal mode their behavior varies according to what is selected. With a note selected, left/right navigates, but with a text element selected they moves the text. On paper it seems odd but in practice it works. So there is a hack within the code for those commands to make that happen.

Someday, it would be great to actually have the hierarchy able to differentiate these so they could be actual different commands in the shortcut list, instead of a single command called "Select next chord / move text right" - that has bugged me for years!

[Tantacrul]

There was a hierarchy system built specifically for MS4 in order to get around all those hacks you mentioned. I'll let @shoogle / @igorkorsukov comment on this.

[Gai-Luron]

I think we should specify a rule (hidden from the user) that when text is selected, CTRL+B should make it bold. In all other cases, it defaults to the append bars action. This should not be exposed to the user. If they change the shortcut for CTRL+B to something else, it will still work to make selected text bold (and while editing text too)

We have the necessary system for assigning key bindings to a 'hierarchy' of purposes. @shoogle @cbjeukendrup and @igorkorsukov know more about this from a technical POV.

For me that sound good. These shortcut are known by many people.

FYI, The Reaper Team has created a very interesting and very powerful Shortcuts module. I don't think it's very important to implement it in MuseScore, but it's interesting to watch their approach.

[igorkorsukov]

We have the necessary system for assigning key bindings to a 'hierarchy' of purposes. @shoogle @cbjeukendrup and @igorkorsukov know more about this from a technical POV.

Yes, we have a shortcut execution context and context priority (some hierarchy).
I don't see that we can hide some shortcuts from the user, but even if it's not this function, we can easily add it.

[iainhallam]

I think we should specify a rule (hidden from the user) that when text is selected, CTRL+B should make it bold. In all other cases, it defaults to the append bars action.

@Tantacrul does that also mean when actually editing text (i.e., typing creates characters in a text context), or only if one has selected text? I often want to toggle bold and italic (and, TBH, underline in lyrics) on and off while writing the text, and having to input the characters, then go back and select those that I want to be affected by a text style will be tedious.

[Tantacrul]

@iainhallam - it wouldn't affect the ability to do that and I agree the user should be able to do that. We just need to build the capability.