In Continuous View, the last visible measure is moved under the continuous panel

• Sep 10, 2014 - 21:29
Type
Graphical (UI)
Severity
S4 - Minor
Status
closed
Project
MuseScore

Configuration

MuseScore 2 Beta 1 on Windows 7 (in VirtualBox).

Steps

  • Create a new score.
  • Choose Continuous View.
  • Choose the Note input mode to start adding notes.
  • Add a note in the last visible measure on the screen:

    Adding a note in the last visible measure on the screen

    MuseScore will automatically move the system to display this last visible measure on the screen as the new first one.

Results: here's the bug: the measure that we're currently editing is moved under the gray rectangle containing key and time signatures, so it's very difficult to continue adding notes:

First measure half hidden

Expected results: the measure that is moved as the new first one on the screen shouldn't be under the gray rectangle, but should be fully visible, for example something like that:

Expected results: first measure fully visible

Attachment Size
01.png 6.8 KB
02.png 6.71 KB
03.png 7.23 KB

Comments

• Sep 13, 2014 - 15:29

Yes, I know and I doubt we can easily fix this one. The problem is that the Continuous panel width isn't known before the score is moved. Continuous panel is redrawn after adjustCanvasPosition is called. So we can't adjust the position of the measure to be sure the panel won't be drawn over it.

One promising strategy I tried locally was to add a function ContinuousPanel::findPanelWidth (int tick) to get the panel width at a certain tick (ie. the cursor position in adjustCanvasPosition), but the rendering of the width caused a crash. Maybe some thread conflicts (the rendering of the panel is quite intensive with all the classes and layouts involved).

So lasconic, if you think that the crash issue could be solved, I can include my function in a PR. Otherwise, I don't know of to deal with this issue.

Reply

• Sep 13, 2014 - 16:40

What about just adding some sort of "fudge factor"? We might not know *for sure* how wide the panel will be, but I'd rather the score be positioned too far to the right than too far to the left. A little extra context never hurt anyone anyhow.

Reply

• Sep 15, 2014 - 14:08
Title Continuous View: the last measure on the screen is moved under the gray rectangle ⇒ In Continuous View, the last visible measure is moved under the continuous panel

Reply

• Dec 13, 2014 - 23:06

vgStef: I'm looking at issues with continuous view (not the panel per se) right now, and am wondering if I could help you resolve this - or if you could me? I could help you find the source of the crash you were seeing, or you could help me find an alternate solution. For example, what about calling adjustCanvasPosition a second time after the panel is drawn?

Reply

• Dec 13, 2014 - 23:31

I don't think we could adjust the canvas a second time without redrawing the panel again. It's really tricky, because if we move the canvas, the panel size might change a lot (ie. from a short keysignature to a long one). I have to go out. But I'll look again at this later.

Reply

• Dec 16, 2014 - 15:59

It seems to me we already account for the (current) widt of the continuous panel in adjustCanvasPosition, so the issue only occurs if the width *increases* as a result of the adjustment. That would happen if there was a key change during the passage, or when the panel first appears.

I still think simply changing this to a fixed margin big enough to account for a treble clef, time signature, and 7 sharps would be acceptable. There's no harm in having too *much* context.

Reply

• Dec 19, 2014 - 05:54

The continous panel is drawn after AdjustCanvasPosition is called. The _ContinuousPnale->width() is the last panel width computed.

I joined an example of a test file I used when I developed the continuous panel.

The detection of the clef, key & time signature is done exactly at the panel width. So depending in which measure it falls, that's what's going to show up in the panel.

It's really tricky, because the can increase or decrease. And if the detection falls into a measure with a much different key/clef/time size, it might overlap the whole a thin measure.

When testing, we need drag the canvas from right to left, and then from left to right. And with different key/clef/time informations, and with different measure width (especially really thin ones).

There are a lot of test cases :
- passing from a thin measure with no key signature to an other very thin measure with a large key signature. On doing it reverse.
- Having many thin measures when the first one has a large key signature forced me to develop the transitional panel width.

Attachment Size
test_continuous_panel.mscz 6.43 KB

Reply

• Jul 7, 2015 - 18:02

For me, the behavior with the current version of the continuous panel is different and definitely better than it was originally. I can still manage to get my cursor to be hidden behind the panel if, after the score repositions upon adding a note, I then undo. Multiple undos keep removing notes but I can't see anything as it is all hidden. Not sure if it makes to reopen this or open a new issue for that.

Reply