GSoC 2020 Week 6 Recap: Warning Warning

Hello again! Last week was a bit of a mixed bag. I didn't accomplish everything I hoped to, but still, progress was made. Let's get into it.

Update from last week

Bugs

My "Priority 1" issue, having to do with undo/redo, was unexpectedly fixed for me by (once again) @mattmcclinch. The "Priority 2" issue, though... I banged my head against the wall all week, and went deep, deep into the weeds with my mentor to figure out what was going on. I wrote many ineffectual lines of code, and deleted them all, because none of them actually yielded a better result than the tiny incomplete fix I eventually committed. The partial fix prevents a bad thing from happening (the disappearance of the clef) but does not cause necessary things to happen instead (the recalculation of the width of measures involved in the group). I want to be very clear: this is bad. And, what's worse, I'm not going to fix it in the near term. However, I feel less guilty knowing that there is a big layout overhaul coming down the pike (see recent posts from @oktophonie), and it's possible the cause of the problem will disappear entirely.

The source of the issue is the way the current layout algorithms try to optimize for speed; they try to layout as little as possible at a time, but in this case they do just a little bit too much. When a system is laid out, the algorithm deliberately messes with the beginning of the following system because that following system may or may not also need to be laid out. And, if it does need to be laid out, then there's actually no problem! When any change is made to the system which holds the grouped measures, they are all laid out correctly. By extension, causing a relayout of the system holding the group will fix them even if they were messed up first. But when an edit is made to the system before the one holding the group, and the system holding the group doesn't need to be laid out itself, then the stretch and spacing of the measures within the group becomes distorted, due it least in part to space being allotted for system headers that are never created. I hope future improvements prevent this from happening. If not, some special handling will have to be added sometime before 4.0 is finished.

Improvements

Meanwhile, I got some other stuff done. At the suggestion of @Tantacrul, I added the option for the user to abort the insertion of a measure repeat if it would cause existing content to be erased. I also added the same thing in the other direction, making sure that inserting a note would cause a measure repeat to be erased while allowing the user to opt out, like so:

Limitations currently: no warning (nor deletion of the measure repeat) when inserting a note via paste or shortcut R; no warning (nor deletion of the measure repeat) when inserting a repeat barline in its midst; no warning (but yes deletion) when changing time signature or measure duration. Incidentally, while testing I discovered that copy and paste of measure repeats themselves currently does none of the necessary work of clearing measures, grouping measures, or hiding rests, let alone warning the user.

I also added a style option (not yet per-element properties) to show extenders (probably a more comprehensible term than "outriggers") for four-measure repeats:

Looking forward to this week

My task list is pretty straightforward, based on what I've described above.
- Handle copy and paste of measure repeats
- Handle paste of notes into measure repeat group
- Handle change of time signature affecting measure repeat group
- Handle change of duration of measure (via Measure Properties) within measure repeat group
- Handle addition of repeat barline in the midst of measure repeat group
- Make extenders available on per-element basis
- Make numbers toggleable