Pushing a system with an horizontal frame causes layout problem
!This seems to be a UI issue and doesn't do any damage that I've found! It's just trippy.
I'm on a fully updated Windows 7 machine. Got the error on the release 2.0.3, but I tested in build 2.1-15a2ba4 also.
Edit any thing in the attached mscz
Hit ctrl+z to undo, or use the undo arrow in the ribbon
(Screenshot attached)
Saving during this does not seem to damage anything, the file reopens normally.
Making any edit returns the UI to normal.
Thought I'd mention because I'm trying out some quarter tone things and added a frame, and I haven't seen much usage of the note element tuning, microtone accidentals or frames.
Attachment | Size |
---|---|
MuseScore ScreenShot.jpg | 197.48 KB |
Characters_without_a_Story.mscz | 10.62 KB |
Comments
Version 2.0.3 and current 2.1 dev. a062dec / Windows7
Steps from scratch:
1) Load this file: frame test.mscz
2) Extend the horizontal frame to the point of creating a second system. Like this (image below)
3) Do: Escape -> Undo -> Redo
(or, alternatively: edit a note, eg the first A to A# -> Undo)
Result:
I observe a change on June 27, 2015.
- With this nightly (June 26: ea43dd9), I get this result after step #2 (and no problem after undo-redo)
- With this one, I get the current behavior and same result after undo-redo (see images in comment #1): 83ae627
So, I presume it's a side effect of this commit ? : https://github.com/musescore/MuseScore/pull/2068/files
For fix: #54221: Horizontal frame before last measure of system creates crowded layout
Thanks for the analysis - wasn't at all obvious the frame was the issue!
I am sure you are right that the fix for #54221: Horizontal frame before last measure of system creates crowded layout is what introduced the bug in this case. However, I do wonder, in that nothing about that code really should have messed with undo behavior. I wonder if maybe the bug was there already but just not seen in this particular case?
"I wonder if maybe the bug was there already but just not seen in this particular case?"
Could you suggest a scenario (steps) to check this ?
The description of the #54221: Horizontal frame before last measure of system creates crowded layout says "the last measure should be pushed to the next system long before it is". That implies it eventually is, if you keep pushing far enough. What happens if you extend the frame that far? Might also need to put more notes in the previous or next measure. Or put two measures before the frame. Not sure. It's also possible that the conditions leading to the bug would never occur without my fix for the other bug, but the bug may have still been there. Or I might be wrong and my fix really is bad - but looking at the code, it really doesn't seem like it should have changed anything about undo specifically.
BTW, workaround is to add an explicit break after the horizontal frame.
With this nightly (the last one before the behavior change as indicated previously: ea43dd9), the handle of the frame comes out of the score (with one, or two measures - I tried- before the frame), and nothing particular after undo.
I see the previous commit, which deals a bit with undo (but for another question, text frames): https://github.com/musescore/MuseScore/pull/2093/files
Could there be something related from a manner or another?
No, I don't think that text frame issue could be related. I still kind of suspect the bug was already lurking and just never had a chance to bite because the conditions that caused it would never happen. Which is to say, I expect the actual code that needs fixing will turn out to lie elsewhere. But it's definitely good information that my change triggers the problem. Regardless of the underlying cause, knowing that this particular bit of code is somehow involved should be helpful. I will try to investigate a bit over the next couple of days, but don't have a ton of time right now.
OK, I think I know what the problem is. It has to do with the fact that we have a different layout routine while doing an undo, and we rely on "hints" set during the previous layout operation to decide where line breaks should happen. My fix for #54221: Horizontal frame before last measure of system creates crowded layout is not setting these properly. Working on a fix.
Well, I still think that's the issue, but my initial attempts at fixing it (explicitly setting the hint on the last measurebase of the system here: https://github.com/musescore/MuseScore/pull/2068/files#diff-fd94ca9d9d9…) have not succeeded. If anyone else wants to give it a shot, be my guest.
Still looking :-). I think maybe actually the issue is we are *ignoring* the break hint on frames. Adding a check for breakHint() here fixes the problem:
https://github.com/musescore/MuseScore/blob/2.1/libmscore/layout.cpp#L2…
But I still don't totally understand how these hints are supposed to work, so I'm not ready to just submit that change as a PR yet.
https://github.com/musescore/MuseScore/pull/3052
Fixed in branch 2.1, commit 7be3ab5d32
fix #180286: bad layout on undo with hbox
Fixed in branch 2.1, commit 993a9fc0a6
Merge pull request #3052 from MarcSabatella/180286-undo-hbox-layout
fix #180286: bad layout on undo with hbox
Automatically closed -- issue fixed for 2 weeks with no activity.