parameter for distance between fret diagram and chord symbol doesn't do anything

I could be wrong, but I think the whole concept of a fretboard frame owning a chord symbol has gone away. So rather than try to make the fretboard diagram adopt the chord symbol - which would probably break other things - the better fix would be to simply check to see if there is a fretboard diagram on the same segment as the chord symbol.

I haven't tested to see if this code actually works or causes any other problems. But in theory at least, getting this option up and running could be as simple as taking the current code in Harmony::Layout() where it checks parent()->type() and uses one "yy" value for SEGMENT and another for FRET_DIAGRAM, and replacing it with code that loops through parent->annotations() (since as far as I can tell parent() is always SEGMENT) and, if it finds a FRET_DIAGRAM with the the same track() value as that of the Harmony object, using the ST_harmonyFretDist value - otherwise doing what it does now.

BTW, I might have assumed from the word of the option that this option sets the distance above the fret diagram and should hence be a small negative value, but it looks like this value is the actual vertical height above the staff, so it has to be big enough to clear the fret diagram. The style option should probably be re-wored to make this clear. Assuming it isn't easy to actually calculate the top of the fret diagram at this point in the code (it's possible it hasn't been computer yet) and apply this as an offset.

I don't think the order they are created in matters. This isn't a constructor - it's the layout() function. layout() isn't called just once on creation of an element, but practically every time you touch anything at all (this is why performance degrades as scores get larger - every single element gets laid out anew on every single operation). So if you create the chord first, it will be laid out in its regular position, but the act of adding the fret diagram will cause layout() to be called again, and this time the fret diagram will be there in the annotation list.

It's probably relatively easy to make Ctrl+K work with a fret diagram selected, too. But considering that most chords are entered via Space or Tab after entering a previous chord, not by clicking individual notes, this change would not really likely to be much of win. You'd probably use that function once per score, then just hit Space or Tab from then on. Assuming you even did the fret diagrams first - my guess is, most people would add those later. So anyhow, if it's simple, sure, no reason not to go for it as far as I am concerned, but it's probably not as useful as the other things you've been looking at.

Nice catch finding that, but unless I'm mistaken, this still doesn't relate to the order in which the user adds the elements, but rather, the order in which they are laid out by MuseScore. That is, when it comes time to lay out segment "s" that has a chord symbol and fret diagram attached, this implies the chord symbol element gets laid out moments before the fret diagram - which unfortunately probably means you can't get a meaningful size/position value from the fret diagram while in Harmony::layout(), because you'll be looking at old values.

So regardless of what order the elements are added in, once both are present, all subsequent layout() operations will do the chord symbol before the fret diagram. The moment you add the chord symbol after the fret diagram - or vice versa - both are present, and ther very next layout operation (which will probably happen milliseconds later - I think most element creation operations conclude by calling layout() although I could be wrong) will lay them both out, and always in that same order.

A couple of things.

First, I don't think it's links() you want - that's for linked staves/parts, I believe. Try annotations(). It's

Second, without testing it, I would reiterate what I said before - while there may at one time have been a concept in MuseScore of a frame that could contain a fret diagram and/or a chord symbol, that all seems to have been removed from the code. Everywhere else it appears to be assumed a chord symbol will have a segment as a parent. So you can't force a chord symbol to have a fret diagram as a parent - that's going break the assumptions made elsewhere. Instead of calling setParent() when you find a match, just set a flag. Then later you set the vertical position based on that.

Also, it looks like your code just checks for the existenceof a fret diagram on the same segment, but you want to make sure it's on the same staff, too. No sense adjusting the position of a chord symbol on the flute staff because of a fret diagram on the guitar staff.

Automatically closed -- issue fixed for 2 weeks with no activity.