Ctrl+Home does not reposition view to first element

• May 6, 2017 - 21:17
Reported version
2.2
Type
Functional
Severity
S5 - Suggestion
Status
closed
Project
MuseScore

Before version 2.1 in Windows (10) pressing Ctrl + Home in continuous view went to the beginning of the score and highlighted the clef sign on the first bar. It now appears to go to the current note however the current note if it was highlighted is not highlighted after the action.

If you highlight the last note in the score, go to the start of the score using the navigator (very messy on a long score) and then click Ctrl + Home you go to the end of the score. BUT the clef sign on the first bar has been highlighted. This is not exactly intuitive! Ctrl + Home should go to the start of the document.

It never worked in Page view but I use this action a lot in Continuous view - I won't go into detail as to why but this not working is a big problem for me. Other than F12 and using the navigator (has that been fixed re slowing everything down) the only work around seems to be to rewind, play and immediately stop. Not very good really.

Not quite sure what Ctrl+End is doing. It used to go to the end but now seems to go the the bar before what was the current highlighted note. Clicking Ctrl+Home, Ctrl+End repeatedly in sequence just cycles around whatever bar contained the original highlighted note.

If you have not selected any note, i.e. on just opening the score, the Ctrl+Home, Ctrl+End work correctly.
GIT commit: 871c8ce

Comments

• May 7, 2017 - 02:21
Status (old) needs info ⇒ closed

OK. My memory is not playing tricks but since one never uses home to go to the top of a document, only to the top of a page, I never tried it.

Reply

• May 7, 2017 - 11:04

No: home should go to the beginning of the line, not beginning of the doc. ctrl-home is to go to the beginning of the doc. It is so in all software and it is also described like that in the wikipedia link you propose.

Reply

• May 7, 2017 - 13:14

Ctrl+Home is set as a shortcut to go to the 1st element ot the score (and Ctrl+End to the last), that apparently is the first clef in the top staff of the 1st measure (resp.the last note in the bottom stave of the last measure), and sets the Input Focus there. I don't think behavoir here changed in 2.1 vs. 2.0.3.
Home alone moves the view to the 1st page, but leaves the input focus where it was, End does the same with moving the view to the last page of the score.

Reply

• May 7, 2017 - 13:20

Oh, please.

Could you indicate which widely used software (except MuseScore of course) has a different behaviour than this:

-When a notion of cursor or currently selected item (and then a notion of current line) exists:

home / end => move cursor/selected item begin/end of current line and scroll if necessary to put the new cursor/selected item visible on screen

ctrl home / ctrl end => same as home/end but to begin/end of document

-When no notion of cursor or selected item exists:

home/end => scroll to begin/end of doc to put it visible on screen

ctrl home/ctrl end => idem

Reply

• May 7, 2017 - 13:51

Whatever, this issue is about an alledged change between 2.1 and 2.0.3

Shortcut management is one of this year's GSoC projects, so maybe the settings you describe here could be done as part of that project

Reply

• May 7, 2017 - 17:56

<< Shortcut management is one of this year's GSoC projects, so maybe the settings you describe here could be done as part of that project >>

Ah, good news thanks. Let's hope it is.

Reply

• May 8, 2017 - 02:54
Status (old) closed ⇒ active

@Jojo-Scmitz #9. Well if it is set to that it certainly is NOT happening in 2.1 and did happen in 2.0.3 exactly as that so basically it has been broken and needs to be fixed.

Reply

• May 9, 2017 - 16:03
Title (Windows) Ctrl+Home functionality changed ⇒ Ctrl+Home does not reposition view to first element

Right now, Ctrl+Home is set to the "first-element" command, which *should* reposition the view. I can confirm that it does not. However, it did not do so in 2.0.3 either, except apparently in Continuous view.

Meanwhile, though, Home *does* work in all cases I've tried.

Reply

• Jun 5, 2017 - 19:09

The reason this does not work is that the code to adjust canvas position to display the current element only works for certain element types when in Page view. Ctrl+Home will normally result in selecting the clef of the first staff, and clefs are among the elements not handled. Similar, Ctrl+End normally results in the final barline being selected, and we don't handle that either. In Continuous view, all works as it should in both 2.0.3 and 2.1.

As far as I can tell, none of this has changed recently. I can verify the exact same behavior in 2.0.3 and indeed going back to 2.0. Prior to 2.0, Ctrl+Home did nothing at all - there was no "first-element" command.

I propose fixing Page view so it works as expected - in addition to *selecting* the first or last element, we should also *position* the view there. But again, I see no change in behavior here. If someone is seeing differently, I would appreciate it if you could attach the score you are having trouble with and precise steps to reproduce the problem, after verifying that it does indeed work differently for you between 2.03 (use portable version if necessary) and 2.1. Otherwise I cannot guarantee will affect the problem you are seeing. because again, for me, I see nothing that works in 2.0.3 but doesn't in 2.1

Reply

• Jun 5, 2017 - 20:20

<< I propose fixing Page view so it works as expected - in addition to *selecting* the first or last element, we should also *position* the view there. >>

Great, thanks!

Reply