Difference between "End" and scroll to end , continuous mode.
When a text box is attached to 1st note, last bar, and is large enough to overhang the last bar line of the piece:
- When use "end" command: desktop shows beyond end bar line to include full text.
- When use scroll to get to end bar line, scroll stops on the last bar line, cutting off the full text.
Comments
Should I put this in the issue tracker? I still don't really understand how all this works.
:)
In reply to Should I put this in the… by xavierjazz
Generally, if something seems like it might be a bug but you aren't sure, best to ask here and wait for confirmation. Once it is confirmed - or if you're absolutely sure even without asking here - then submit to the issue tracker.
I'm not understanding the issue, though. I don't have any problem scrolling all the way to to the end of a score with text handing off the final barline - I just keep scrolling until I can see it all. The "End" key actually ignores text, it's just trying to position the final barline a comfortable distance from the edge of the screen. Ctrl+End, however, does put the selected barline all the way to right edge, which seems inconsistent. So to the extend it doesn't do what End does - add a little breathing room - that seems like a "minor" bug, in the "graphical" category (affects the UI, not the score itself).
In reply to Generally, if something… by Marc Sabatella
That's my expectation, "end". If something protrudes (as the text box does), one would expect that "end" should include it.
In reply to That's my expectation, "end"… by xavierjazz
That's reasonable. But unfortunately we don't really have easy access to that information. If we did, we'd probably have a solution for that same text potentially extending into the right margin or clean off the page in page view. Well, it's possible to calculate the info, and just having it doesn't tell us how how to sovle the problem of text extending into the margin, so it's not as simple as that. But anyhow, worth submitting as a Suggestion tot eh issue tracker for sure, but my guess is, it would probably not be implemented until we have a way of dealing with this sort of thing more generally.
In reply to That's reasonable. But… by Marc Sabatella
Is the text box not an "element"? Can the pointer not just point to the "end of end element"?
Exposing my ignorance. :)
In reply to Is the text box not an … by xavierjazz
The text is indeed an element - but it's not the last element. The barline is. The text is an earlier element that just happens to be large enough that it extends past the last element. Problem is, we have no idea where there might be other elements that might extend past that barline - really, you could have an extremely long text several measures earlier that does. So there is no straightforward way to find the element that actually extends further to the right except by an exhaustive search of all elements checking their boundaries. Whereas, we can easily go right to the last element in one line of code.
So until we have a data strucutre that better allows us to answer questions like, "which element is the further right of any", changing this behavior would be awkward. But having such a data structure would be useful in solving the other kinds of more serious problems, so I do suspect it will happen someday. And having this suggestion recorded so we remember to actually solve both problems at once is definitely useful.