Frames - implementation issues?
Create a new score of linked guitar staff/Tab (as in the template). Make sure there are enough bars for at least 3 systems:
Text frames
Append a text frame to the score and fill it with a few lines of text ("The quick brown fox jumped over the lazy dog," cut and pasted a few times, say). Click on the text-frame only (NOT the text). This brings up some values in the Inspector:
(1) The "Top Gap" only works with positive values. You can't use negative values to set the frame nearer to the previous system. Surely, in this case, the local value should override the global value (set in style > general > page > vertical frame top margin), and it should be possible to move the text-frame closer to the previous system with a negative value of "Top Gap." "Bottom Gap" only works if there is another frame underneath (which in this case there isn't).
(2) "Top margin" has no effect. "Right margin" has no effect. "Left Margin" and "Bottom Margin" affect the placement of text, though you would expect this value to be called "padding" rather than "margin."
Adjusting left and bottom margins causes the text to "leave" the frame. Surely the idea of a frame is that the contents stay within the frame?
(3) "Height" does not change anything.
In short, implementation is incomplete and confusing. Some of the fields are redundant.
Vertical frames
I also experimented with vertical frames and encoutered many of the same issues. You can, apparently insert a horizontal frame within the vertical frame, alter the width and drag it over to the right hand side. The trouble is there seems to be no way to drag it back to the left again. It proved impossible to set up two horizontal frames to contain two columns of text for lyrics.
Selecting a vertical frame in the middle of the score and using the "insert horizontal frame" (from the menu) added a horizontal frame to the end of the score!
The handbook has nothing about "text frames" at all in it.
Comments
More on Vertical frames
HF = Horizontal frame; VF = Vertical frame
The attached file shows a HF in a VF. This setup has been used to create a 2-column effect. The HF was added from the VF right-click menu. It's length was adjusted to approx 1/2 the VF width, then ctrl + click was used to slide it to the right (but once it has gone to the right you can't slide it back to the left again).
A few observations:
(1) The height of the VF does not expand to accomodate the added text!
(2) The handle of the HF can be extended off the page as far as you like!
(3) "Left gap" and "right gap" fields appear to have no effect whatsoever.
(4) If you click on the text in the HF (on the right) you can drag it any way you like out of the frame! Why have a frame boundary when text is free to move outside it?
(5) Ctrl + click on the same text and you also drag the HF with it to the left, but the movement becomes unpredictable and difficult to control!
Expected behaviour: Ideally the user should be able to drag the HF left or right within the VF, and the movement should be predicatable and controllable. And the text should simply stay within the bounds of the frame in which it was created.
In reply to More on Vertical frames HF = by geetar
Vertical frames are not intended to be auto-expanding. That's why text frames were added. The height of a fvertical frame is controlled directly - double click and drag handle, or use Height in Inspector.
It does seem to be true that left & right gap are not currently used.
As for why to allow frame to be moved outside a frame, it's a pretty common thing for people to want to do, to allow text positioned at relatively arbitrary places on the page but still relative to the music in some way.
I don't understand #5. Ctrl+drag is the way to constrain dragging horizontally, and that's exactly what it does for me. Perhaps you actually had the horizontal frame selected when you did the initial Ctrl+click, which had the effect of adding the frame to the selection?
Text frames are a relatively new addition, that's probably why there is nothing yet in the Handbook. Feel free to propose wording.
Top margin works fine for me - sets the distance of the text from the top of the frame. So does bottom gap, with or without a a frame underneath (eg, it works fine with a regular systsem underneath). Can you post the specific score you are having problems with and precise steps to reproduce the problem you are seeing?
Height is indeed irrelevant for text frames; the height is computed automatically. It should probably be grayed out.
Feel free to submit a feature request to add support for negative "top gap" values.
Regarding vertical frame, I don't know which issues specifically you are seeing, but everything you described works as expected for me - all margins, gaps, etc, and height works as intended. Just the feature request for negative top gap seems applicable.
Yes, using the main menu to insert / append items affects the score as a whole. The right click menu is the way to insert within a frame. That could stand to be revisited, feel free to submit an issue.
It is indeed somewhat difficult to position horizontal frames within vertical frames. But Ctrl+R resets position of any element to default. In any case, should be easy enough to set up two columns: add frame, resize, drag right, add another frame, resize.
In reply to Text frames are a relatively by Marc Sabatella
I guess text frames should get their own inspector, like vertical frame, but without height.
See https://github.com/musescore/MuseScore/pull/2077
The behaviour of frames needs to be consistent, sensible and eliminate "redundancy of choice." This isn't always the case with the current implementation of frames:
(1) When you have inserted/appended a vertical frame, it cannot be dragged on its own. But if you accidentally select the frame with its text, it may move in a haphazard way with the text. This incidental movement of the frame serves no purpose whatsoever.
The logical answer is, surely, that once the Vertical ot Text frame is in place, it should be locked into position so that it cannot be accidentally selected and dragged with text. It can then only be moved up and down using the "top gap" and "bottom gap" settings.
(2) Copying and pasting between frames seems to be hit and miss. Sometimes it works sometimes it doesn't. If you cut all text from a text frame and repaste it back to the same frame, the text frame loses its ability to expand vertically.
(3) The frame handle on HFs can be dragged backwards to give a negative width! The same may be true for VFs as well!
(4) When a VF is inserted between systems, negative values of "bottom gap" affect placement but not negative values of "top gap."
(5) Ctrl + Z does not always work to undo any problems with frames.
(6) HF in a VF. What is so special about a HF in a VF that cannot be done simply with a VF on its own? After all, you can place several text objects in a VF and they all have independent movement and styles; you can create columns without using a HF in a VF.
(7) Single clicking on a VF or TF allows you to edit the frame in the inspector and to gain access to the right-click menu. But you have to double click to access the editing handle. Why can't all of these functions be accessed by a single-click on the frame and double-click reserved for accessing the actual content of the frame, such as text, images?
In reply to The behaviour of frames needs by geetar
Re: #2 - if you have a way to reproduce, please open an issue and attach the score and precise steps.
#3 is reported already in issue tracker
#4 - this is just restating what you wrote previously, right? As I said, feel free to open a feature request to support negative top gaps.
#5 - again, if you see a specific issue, please file it with score and steps
#6 HF in a VF is the only way I know to get right aligned text that is not aligned all the way to the right margin but to some intermediate point with the frame.
#7 - double click is how to access edit mode not just for frames but for all elements that support it. I don't see what would be gained by breaking this consistency here.