New features and improvements for fretboard diagrams

[mike-spa]

A big revamp of our fretboard diagrams, including

• A completely redesigned style dialog (some options are different, some are new)
• New option for slur-styled barré
• New option for custom fret number suffix
• New option for trimmed-style (default) or extended-style diagrams
• New option for entering and displaying fingering (with related UI components to edit them in property panel)
• Many small engraving improvements and corrections.

Note: the underlying code is really not in a good state. The drawing code is especially problematic, with lots of repeated code, and especially lots of stuff that shouldn't be there at all but should be moved to the layout code, but I don't have the time at the moment to fix it all, so I did little pieces where I could. We'll have to come back to it and tidy it up properly.

[ghost]

Permit me to add:

1. Use 'Barré' (with the diacritic) in the Style dialog
2. Where there is a slur-style barré, dots should not be shown at the barré position where that string has a dot at another position (or, conversely: dots should be shown if there are no dots at another position). e.g:

[mike-spa]

@avvvvve

1. ✅ Fixed
2. ✅ Fixed
3. ✅ Fixed
4. ❌ I couldnt' figure this one out. Also because, at least on my machine, it doesn't always happen. And I still haven't understood exactly which conditions cause it to happen. I may have to enlist help.
5. ✅ Fixed (this was just an update issue: you would have found the additional fingering element by closing and reopening the panel)
6. ✅ Fixed
7. ✅ Fixed
8. ✅ Fixed
9. ❌ I disagree on this one. The diagram is normally entered above a note and is vertically centered with the notehead, and it's important that it stays centered at any magnification level. I don't think you'd normally write a diagram on an empty bar. In this case it is just centering itself on "where the first note would be" if the bar had any note. @oktophonie do you think it's worth adding some special case here for diagrams on an empty bar (e.g. centering them in the bar?)
10. ❌ Can't reproduce it on my machine (and it's very likely a problem that predates this PR, so it's not to be fixed here)
11. ✅ Fixed
12. ✅ Fixed

@oktophonie

1. ✅ Fixed
2. ✅ Fixed

[avvvvve]

@mike-spa Re 4: For what it's worth, it happens every time on my machine (macOS 14.5) Re 9: Makes sense!

A couple more things:

13. The bottom of the Fretboard diagram style page is now cut off (unless I resize the window to be really tall)

14. When there are two rows in the "Show fingerings" section, let's make the space between the bottom of the text boxes in the first row and the number circles in the second row 12px.

15. Changing nut thickness with orientation on horizontal expands the diagram to the left, rather than keeping it centered on the beat position.

16. If you change orientation to horizontal, the fret number position radio buttons should change from "Left" and "Right" to "Bottom" and "Top"

Nice-to-haves (I'll log any of these as separate issues if you like):

• If you set orientation to horizontal, diagrams with fret numbers below get vertically staggered. Perhaps they should all be top-aligned with each other on the system? @oktophonie can weigh in here

  

• Re 5: It would be great if changing the string number could automatically affect the number of fingerings shown in properties without having to reselect the diagram to update the view

[mike-spa]

@avvvvve

13. ✅ Done (sorry)
14. ✅ Done
15. This is also intentional, meaning that the digram stays centered on the center of the "main grid" area (which in 99% aligns with the center fret line, which I think makes it look better). Also I think it's highly unlikely that anyone would increase the nut thickness so much as to make it look off-centered, but @oktophonie do weigh in on this.
16. ✅ Done

Nice to have:

1. I'd certainly love to, but it's a very difficult thing and it will have to wait until we have a generalized alignment system.
2. ✅ Done!

[cbjeukendrup]

I looked at the unsolved issue 4 from above. This is what I just wrote to Michele about this:

I’ve figured out the problem. It’s a bit nasty. What happens is the following:

1. You click on another text field
2. That text field gets focus and the previous text field loses focus
3. The previous text field calls its onTextEditingFinished handler, and updates the model
4. The model notifies that the fingerings property has changed
5. Repeater throws away all components it has created, and replaces them with completely new ones. The new ones don’t have focus, so the result of step 1 and 2 is lost.

The solution is probably to use something smarter than Repeater, which almost directly means using GridView, but that is very limited in its layout possibilities (i.e. number of columns, column spacing…) So I’ll either have to work around those limitations, or still find a way without GridView that works too.