Horizontal offset of a line's Begin Text
I know the line number and code (or at least as it was back in 2.3 timeframe) as to how to change the current behavior of the horizontal offset of a line's begin-text to be in unison with the end-text's behavior related to its horizontal offsetting, but the current behavior now is equivalent to the effect of extending its line to the left or right in general. That is, any horizontal offsetting of begin text is not equivalent to the horizontal offsetting of end text as it currently is, and this is the proposed behavior: to make them equivalent (allow the begin text to be moved in position without changing the line's positioning so that text can be buttressed for a symbol without space, or begin at the beginning of the line and above it (with vertical offset) instead of being restricted to the left of the line.
Instead of extending the line or contracting it when horizontal offset is used of the begin-text, the line itself should stay put as with the behavior of horizontal offset of end-text.
Marc mentioned that a discussion should be had as to whether or not it should be changed, since someone might make use of how currently is, and to change it would break their scores, although it would be really weird, imo, to make use of horizontal offsetting of a line this way since it is equivalent to merely dragging the line's terminal point one way or the other horizontally (or using the keyboard to do so), and the text's offset, imo, should be separate from that action.
Haven't done a pull request in a long time, so i'll have to set it back up if it works out. Anyways, any comments or objections about the request?
Comments
I agree.
The "start text" should be considered as a child of the TextLine object; its offset should be relative to the origin of its parent and affect the start text itself only. If one wishes to move both the start text and the line itself, changing the offset of the parent will still allow that.
Right now, it's a bit different. The offset for the line moves the entire line, but the offset for the text moves the text and the endpoint of the line closest to that text. So it's like using the drag or cursor keys (without Shift) on that endpoint - something not otherwise covered in the Inspector.
It's really that usage I am concerned with - the fact that right now this Inspector setting does have a useful function not covered by anything else in the Inspector and that some may be relying on. Perhaps there should be Inspector settings corresponding to the endpoint adjustments for lines. Maybe also for the interior points on slurs. Although documenting exactly what those mean would be tricky, but that that doesn't stop us from providing the utterly confusing Inspector settings for beam adjustments.
Another thing: right now, the line by default starts not with the first note, but at some point just to the right of the end of the text. I would suggest that once we start messing with the position of the text indepedently, that start point for the line no longer makes sense. What's so special about that point just to the right of where the text used to end? So that's another concern I have with having the text move independently - it really leaves the start position of the line itself in a meaningless position.
As it is, you can move the text independently of the line start point, if you first change the "placement" of the text from the default "auto" (or equivalent "left") to either "above" or "below". At that point, things start working more as one might expect in this context: the line itself starts at the note it is attached to, text is ignored. And then the offset for the text moves the text alone.
Meaning, that's really the "right" way to get the effect I assume you are after here: a line in a predictable fixed position while you move the text around. If you want that line to start somewhere other than directly above the note it is attached to, you can change the line length normally (same as you would if there no text) using the mouse or cursor keys.
Anyhow, I'm fine with the basic idea that there is room for improvement here, there's just way more to it than meets the eye.
In reply to Right now, it's a bit… by Marc Sabatella
Ok. The suggestion to change from auto to any other besides left does indeed take into account the x-offsetting in such a way that the line doesn't follow suit, and so this will allow for the behavior as mentioned. Although, it does seem a little strange to require this depending on how the functionality is seen. That is, a user can quickly be under the impression that the ability doesn't exist by the fact that default x-offsetting of a begin-text doesn't move the text independently from the line (should probably check to make sure the handbook incorporates this information). Thanks for the tip.
P.S. Back in the 2.x days, when this issue was first noticed, the user had to get into a separate dialogue for the properties of the line, then get into the style setting to set this stuff, and then realize that auto had to be changed. It was quite a hassle compared to how 3.x is working
While we're on the topic though, here's another problem with lines -- off topic a bit but very similar while we're here: When a fresh line has been emplaced... the first time the left most anchor point is dragged actually doesn't drag it but the right-most point! This seems totally totally absurd (here's a gif capture):
In reply to Ok. The suggestion to change… by worldwideweary
RIght, it's not great now but things are better and can be improved further.
The GIF shows a known bug, see #283357: Lines: dragging left handle to the right causes right-handle to move left