Keyboard nav "Quality of Life" issues
Currently, there are a few issues with keyboard navigation through a score.
- Keyboard nav in the Single Page view is quite broken. PgDn and End has no effect and both PgUp and Home has the identical effect of moving the canvas so that the start of the score is in view. I would propose the following:
- Keep Home's behaviour the same, but let PgUp be moving up roughly one screen at a time (similar to what it does in Continuous View, but only moving up instead of left).
*Change End's behaviour to put the last measure in focus (also similar to Continuous View).
*Change PgDn's behaviour to scroll down roughly one screen at a time (yet again similar to Continous View).
- In Page View, you can not navigate to the end of the score with the keyboard. Currently, End goes to the top of the last page and PgDn also stops doing anything when the top of the last page is reached. I would propose the following:
- Change End's behaviour to bring the final element in the score (i.e. the element with the largest x offset on the last page) into focus.
- Make PgDn do the same as End if it is pressed with the last page already in view. [I need opinions what percentage of the last page visible on screen counts as "in view"]
I would like opinions about this proposal. When we figured out what we want, I'll divide this into tasks belonging together and make separate issues for each.
Comments
I definitely support looking at this. Some of my observations:
In page view, End goes to the last page, but to the top left of the page rather than the bottom right. I'd like to see that changed, but would personally suggest just using the actual page dimension rather than hunting around for elements with particular X offsets.
Ctrl+Home selects the first element (well, aside from the title frame, seems good to me) and repositions the view. Ctrl+End selects the last elements but fails to reposition the view correctly. This too should be fixed.
Ctrl+Shift+End does select to end and reposition the view. That's my trick for getting to the end. :-)
In reply to I definitely support looking… by Marc Sabatella
About your first point: Consider a page with only one system right at the top and only one measure too narrow to pass the system fill threshold. End as you describe would annoy me as user in this scenario. I am thinking about a "word processor-like" End behaviour. End should put the last element of the document into view, regardless of its position on the page (xpos and ypos, which can both be a problem if the zoom level is high enough).
About the other two, noted, thanks. Will try to fix them too. Thanks anyway for the input. Always appreciated.
In reply to About your first point:… by Louis Cloete
Good point, last element is fine. I'd just suggest using the same definition of "last element" as Ctrl+End. Sounded at first like you were talking about searching an element with the largest X offset.
In reply to I definitely support looking… by Marc Sabatella
So the "first element" and "last element" here are barlines? Rather than notes/rests?
For me they are behaving slightly differently: you can plain-old-right-arrow away from the initial barline, but the final barline requires alt+left-arrow.
And Ctrl+Shift+End is not doing anything. Is this a current or hypothetical feature?
Ok, so I fixed the single page problems (#284788: Keyboard nav in Single Page view broken). Next, I want to tackle the way the four keys in question work in page view, both in vertical and horizontal view. I am describing my preliminary ideas here (supplementary to what I already described in my first post).
Vertical scrolling
Home
I am happy with Home's current behaviour.
End
I am going to try to get End to put the final barline of the bottom staff of the last system on the last page into focus. The challenge will be to get it to do reasonable things when the last system only uses the left 20% of the page. I think I should try to fit the page's right margin on the canvas as well as the whole of the last measure's width. I don't know what should happen if both are not possible. (Ideas, please ;-) )
PgUp
PgUp can stay as it is, but I think it will be good if it can be changed to not go up a full page at a time, but only a screen. Ctrl (Cmd) + PgUp can take over MS2's behaviour (moving to the top of the previous page). PgUp should also never change the x offset of the page on the canvas. If you have zoomed in, PgUp should also keep the same vertical strip in view, not move the page so that the left edge is in view on the left side of the canvas.
PgDn
PgDn should at least get an upgrade in its behaviour when pressed on the last page to be similar to my proposed behaviour for End. That means that it will put the last system into view. I think that PgDn should, like PgUp, never fiddle with x offsets (it differs from End in that respect). It should also, as PgUp, not move one page at a time, but one screen at a time. Ctrl (Cmd) + PgDn should take over MS2's behaviour (moving to the top of the next page).
Horizontal scrolling
Home and End can behave identically to the vertical scrolling case. PgUp and PgDn should be given more thought. I am also awaiting input from regular users of horizontal scrolling (I normally use vertical scrolling). My gut feeling, however, is that I can implement things as for vertical scrolling and horizontal scrolling should be at least usable.
PLEASE COMMENT
PS: I am open to different ideas. This is my first major endeavour in designing a piece of software and I am also not the longest user of MuseScore either. Most importantly, the result of this conversation should make life easier for you, the user of MuseScore. So tell me if my proposal will do the opposite for you!
In reply to Ok, so I fixed the single… by Louis Cloete
IMO, Home, End, and the Page keys by themselves should work on navigation within a page, to be consistent with other word processing behaviors most of us have gotten used to. It would be logical if Home takes you to the first element in the first system on the current page, and End takes you to the last element in the page (and yes, padding the view a little so the selected element is brought closer to center screen would help a lot). PgUp and PgDn (by themselves), i agree, should go up one page of the VIEW, not the score, as you suggested.
We can then allow for modifier keys to exhibit more extreme behavior. So, for example, Ctrl-Home would go to the first element of the the first page of the SCORE, rather than the view, and similarly with, say, Ctrl-End. Ctrl-PgUp & Ctrl-PgDn would move up or down one page of the actual score instead of the view (whether horizontal or vertical in view).
Then when navigating with the modifier+PgUp/PgDn keys where does it actually go? Perhaps choosing the same view coordinates in the previous/next page (maybe from top-left of the current page using the same zoom level) would be best, but would it select an element in the new view? That will probably need to be discussed...
Now, if Scroll Lock is on, nothing new should be selected. Instead, these keys only change the view (keeping the same zoom), in case all a user needs to do is review note entry in another part of the score. Then when he goes to continue input at the selection point, the original view is recalled.
I like the idea of standardizing these "word-processing" behaviors, and consensus among users would definitely advance usability.
In reply to IMO, Home, End, and the Page… by harbinger
@harbinger I totally agree. The results of using navigation keys are so strange I don't use them in MuseScore.
In reply to IMO, Home, End, and the Page… by harbinger
I agree with you about trying to standardise, but I thought more of standard browser behaviour when text isn't selected. In both Internet Explorer and Chrome, Home takes you to the top of the web page. It works similar to Ctrl + Home in a word processor. Likewise, End takes you to the bottom of the page. Compare also Adobe Acrobat PDF reader. I think MuseScore is more analogous to a browser or PDF reader, because you would also normally only navigate the view with the four keys in question. You don't want to move around the text input cursor, as in a word processor (except of course when you are editing text elements).
Anyway, this is still very much in flux. I will not get around to doing this before next week at the earliest. I am away for the weekend. So you have till at least next Monday to try and convince me otherwise ;-)
In reply to I agree with you about… by Louis Cloete
And unfortunately, standard behaviors for things like this often differ between Windows, macOS, and Linux.
In reply to And unfortunately, standard… by Marc Sabatella
Then in this multi-platform environment define the keys according to the OS rather than making them so different from normal on windows.
In reply to Then in this multi-platform… by mike320
You see, the problem is that I don't perceive the shortcuts as is as being so different from normal on Windows. It is what I expect them to be considering the nature of the program. I expect browser-like behaviour.
Anyway, this is what this thread is for: to differ enough about how things should work to finally agree about an implementation.
In reply to You see, the problem is that… by Louis Cloete
Well, if you think about it, all you're doing is creating processes. All of us can assign the shortcuts we want. It seems to be that, for example, one function will change the view by going to a particular coordinate at another location, another function will select an item equivalent to the one on the current except at the next/previous, etc.
Just invent the navigation functions, we'll vote on which should be the default keypresses, then we'll go from there...
Here's the functions that i think MuseScore should incorporate (in regards to the word-processing keys):
1. First page of score, view only (nothing selected, input cursor remains at same place)
2. First page of score, select first element on first staff
3. Last page of score, view only
4. Last page of score, select last element on last staff
5. Previous screen*, view only
6. Previous screen*, select first (last?) element in this view (if any)
7. Next screen*, view only
8. Next screen*, select first element in view (if any)
9. Previous page of score, view only
10. Previous page of score, select first (last?) element in page
11. Next page of score, view only
12. Next page of score, select first element in page
/* maintaining zoom level and page coordinates
Regarding point 6 & 10, the reason you may want the LAST element is in case you are going backwards in study or review of the score.
Overall, not only should these standards make it easy for sighted users, but also make it immensely easier for blind or near-blind users.
In reply to Well, if you think about it,… by harbinger
Indeed clarifying the navigation functions to offer in the shortcuts preferences should get unanimity.
Then assigning default keys to them could degenerate in endless discussions, but they can be shortened by taking quick decision knowing that everybody will be free to redefine them if he is not happy with default.
In reply to Indeed clarifying the… by frfancha
Please read also https://musescore.org/en/node/109261
I would love these abilities. Unfortunately, my Mac doesn't have PgUp, PgDown, or End. How will this be available on Mac?
In reply to I would love these abilities… by [DELETED] 1831606
I don't know how Mac handles this, so my answer would be, "Get a Windows computer" ;-)
In reply to I don't know how Mac handles… by Louis Cloete
Get a Mac, Jack : ). Clearly whoever implements this surely ought make a way. I regularly need to go to the ends of scores without losing the selection (to mark an entire staff, which maybe could be easier), and always have to try 2 or 3 times because of accidental score-touching during scrolling ...
In reply to Get Mac, Jack : ). Clearly… by [DELETED] 1831606
I will try to find out if Mac has a default key analogous to each of the actions discussed above.
In reply to I will try to find out if… by Louis Cloete
If not, I can hopefully assign them ....
In reply to I will try to find out if… by Louis Cloete
It has been years, but if memory serves, Fn+arrow keys allowed me to use the page up/down features in Sibelius on my 2006 MacBook.
In reply to I would love these abilities… by [DELETED] 1831606
Most Windows computers and Chromebooks that lack these keys implement them as something like Fn+Up for page up, Fn+Left for home, etc. In fact it works even on computers that do have these keys, and I actually find those shortcuts more convenient on my Surface, which places the real PgUp et al in a less convenient location.
I've always assumed Fn+cursor works on Mac as well. Give it a shot and let us know. To be clear - these keys already function at least in page view; just maybe not quite as well as they would with the proposed changes. I can't imagine life without Fn+Up/Down for paging through a score.
In reply to Most Windows computers and… by Marc Sabatella
!?!?! Isn't science wonderful!?!?! These actually do something! Fn+Command+[arrow-right] actually gets me to the end of the score! Thank you!!!!! I have wanted this for so long!
In reply to !?!?! Isn't science… by [DELETED] 1831606
Fn left and Fn right work as you say! How could I not have known this!?!?
In reply to Fn left and Fn right work as… by [DELETED] 1831606
I find it's extremely common for Mac users to be unfamiliar with those, as many also are with "right click". I guess because there is no dedicated hardware to these functions on most (all?) Macs, people tend to not discover them on their own. That's why these always make my shortlist of most valuable tips & tricks when giving any sort of presentation on MuseScore.
In reply to I find it's extremely common… by Marc Sabatella
Guess they should get documented in our handbook.
Not that users would actually read it ;-), but then at least we can point tham to it...
In reply to Guess they should get… by Jojo-Schmitz
And then I, who only worked on Windows my whole life, can also answer these kinds of questions.
In reply to I find it's extremely common… by Marc Sabatella
BTW, in case it isn't clear: this isn't just MuseScore; these shortcuts should be functional in all applications, assuming they implemented commands for them. Like, I'd be quite surprised if your favorite web browser doesn't respond to Fn+Up/Down. But yeah, I know there are places in the Handbook where we make a point of telling Mac users how to access "right click" and the whole bit about Ctrl->Cmd etc, this would be good to include as well there up front, and then where possible update individual pages.
Also, FWIW, the commands are customizable in MuseScore, see "Page: End" etc. So even if your keyboard doens't map Fn + cursor to these, you can activate the commands on whatever else you like. If new navigation commands are added, they should be done in the same way.
In reply to Fn left and Fn right work as… by [DELETED] 1831606
No one ever told you?😉
In reply to No one ever told you?😉 by mike320
No!
In reply to Fn left and Fn right work as… by [DELETED] 1831606
Yay! One less thing to worry about when I implement this.
In reply to Yay! One less thing to worry… by Louis Cloete
Indeed! We both win!
I have started to implement some of the features discussed here. Doing so, I realised that the current behaviour of MuseScore doesn't differentiate between if an element is selected or not when deciding what to do in reaction to the navigation keys. I would propose the following:
Nothing selected: Works analogous to a web browser or Adobe Acrobat type of programs. Arrow keys currently does nothing. Needs to be implemented.
Notes selected: Works more like a word processor. Arrow keys already implemented.
What are your thoughts?
In reply to I have started to implement… by Louis Cloete
Agree ! That was one of my proposal some years ago and approved by Marc himself at that Time ;-)
In reply to Agree ! That was one of my… by frfancha
OK so I am going ahead then ;-) What I will do:
Nothing selected:
PgUp/PgDn: moves up/down one screen.
Ctrl (Cmd) + PgUp/PgDn: moves up/down one page (if pages exist. Else does what PgUp/Dn does without the Ctrl key).
Home: moves to the top of the score. Moves both the x and y pos so that the top left corner of the score is in view and the first element is visible. Should I only change the y pos? (x and y pos change places if we are discussing Continuous View.)
End: moves to the bottom of the score. Moves both x and y pos so that the last measure is in view. Ensures that the left margin of the page is at the left edge of the view or to the left of the left edge of the view (i.e. surpress lots of blank space to the left of the page) and align the last measure more to the right of the view in other cases.
Ctrl (Cmd) + Home/End: currently selects the first/last element in the score. Should I keep that as is, or change it to do the same as Home/End without the Ctrl key?
Arrow keys: move the page up/down/left/right the same amount that one click of the mouse wheel currently does.
Ctrl (Cmd) + arrow keys: ignore the Ctrl key and do the same as for arrow keys?
ChordRest selected:
PgUp/PgDn: this one is a bit of a problem for me. Should I lose the selection and treat it the same as without selection? Should I try to move the selection to a reasonable place? Should I keep selection and move the view?
Ctrl (Cmd) + PgUp/PgDn: this one is easier: just move to the top of the next page and select the first element or move to the top of the current page if the top of the current page is not in view or else the top of the previous page and select the first ChordRest.
Arrow keys: keep as is.
Ctrl (Cmd) + arrow keys: keep as is or make it honour the voice if possible? Currently, selecting a voice other than 1 CR and pressing Ctrl + left arrow selects the note in voice 1 on beat 1 of the measure.
Any other element selected:
Keep behaviour as is. This means I will do regression tests to see if my changes made MuseScore behave differently in this case, but I am not going to do anything new for it for the time being.
In reply to OK so I am going ahead then … by Louis Cloete
Hi,
For me when nothing is selected, ctrl home/end should move the view to show start/end of doc, but NOT select anything, in order to allow to continue to navigate with arrows, pgdown/up,...
And with nothing selected, Home and end should move view start/end of current line.
To be coherent with their behaviour when a note is selected.
Already a big thanks for you work, that will greatly contribute to the ease of use of MuseScore.
In reply to Hi, For me when nothing is… by frfancha
The behaviour of Home and End with nothing selected will not be very useful if it only moves to the start/end of the line. I think it is a good enough argument to break strict consistency. That is also how Home and End without Ctrl work in browser like programs and Adobe Acrobat. People will quickly grasp what it does even if it is strange the first time.
In reply to The behaviour of Home and… by Louis Cloete
Except that you already have ctrl Home and end to go start and end of doc, so no reason to sacrifice consistency of Home/end to go there as well.
And a page often doesn't fit on screen in width, so once you use the keyboard to navigate going start/end of line would be very useful.
All I ask is that you make sure that Mac keystrokes are available, documented clearly, and work.
I have looked at Finale, Sibelius and Dorico's keyboard shortcuts, and there doesn't seem to be any consensus about what a music notation editor should do. I am thus making this proposal: don't shift selection on any of these keypresses for now. Just keep the selection where it was and let them do the following:
PgUp:
Move up (left in continuous view) one screen at a time.
PgDn:
Move down (right in CV) one screen at a time.
Home:
Move to the start of the system (or score for Continuous View only).
End:
Move to the end of the system (or score for Continuous View only).
Ctrl + PgUp/Dn:
Move a page at a time up or down in Page View, else do what PgUp/Dn does without Ctrl.
Ctrl + Home/End:
Move to the start/end of the score.
I am getting a bit entangled in ideas and opinions at the moment, so I am going to ask Anatoly, Werner and Dimitri what they think about this before I go on.
In reply to I have looked at Finale,… by Louis Cloete
I have a proposal for continuous view. Since ctrl+home/end moves to the ends of the score, make home move to the top staff and end to the last staff in a system keeping the same measures visible. This would be very nice when entering a symphonic score with 45 instruments.
In reply to I have a proposal for… by mike320
I like the idea. Will see what I can do.
In reply to I have looked at Finale,… by Louis Cloete
My personal opinion:
Losing selection unexpectedly is bad. Selection should change only if the user specifically asks for it, and we should be clear on what constitutes navigation vs selection change. I like the model that Home/ End, PgUp, and PgDn keys on their own move the view but don't change selection, but if Ctrl+Home/End change the view and also select the first/last element, that's fine - if for no reason than this is what we are used to. But I think I prefer the idea it doesn't change the selection - it's not like the opening clef or final barline are likely to be things you want to select. As long as Shift still extends selection that way, which I suppose is really the reason why Ctrl currently does select.
I have no particular expectation about Ctrl+PgUp/Dn., but what you propose makes sense.
In reply to My personal opinion: Losing… by Marc Sabatella
Yes, that is exactly what I thought too. If you want to select the first/last element in the page/score, you can always use Shift and then do right/left arrow to only retain the element you want. More keystrokes than just Ctrl + Home, but I am also very much thinking about accessibility here. A user who cannot use the mouse must be able to reach any part of the score easily without losing selection and move selection to any place relatively easily.