Rt click measure/staff property positioning changes ...........
Rt click measure/staff property positioning changes depending on whether it is clicked on the bottom or top half of the staff.
This adds nothing but a complication to the function.
I suggest the positioning be fixed no matter where in the staff it is clicked. Then I won't have to hunt for it each time. :)
EDIT: Actually it doesn't seem dependent on where you click it, it just seems random.
Comments
Do you mean that Staff/Measure Properties appear at different heights in the popup menu? If so, that depends on whether MuseScore thinks you right-clicked on or near an element within the measure. If you click near a note or rest, then Staff/Measure Properties move to the top of the popup and a Note or Rest submenu appears below. (If you click near a slur or stem or bar line, you get a menu just for it and Staff and Measure Properties don't appear at all.)
In reply to Do you mean that by Seamas
Perhaps that is the explanation, but I think menus should be standardized as much as possible. To me this is a bug. Why is it bouncing around?
In reply to Perhaps that is the by xavierjazz
I don't think of Measure Properties and Staff Properties as "moved" so much as "inserted." Any time you right-click on something other than blank space, MuseScore tries to identify what element you clicked on. If it's a particular thing—a note, slur, clef, bar line, text—MuseScore gives you a popup menu tailored to that item. In particular, the Style and Select► menu items are specific to the type of element you clicked on.
But measures and staves are different: They're collections of elements. Their menus are different from single elements, and appear when you right-click without selecting a particular element. (Getting to those menus is sometimes tricky; I've had trouble myself occasionally, trying to right-click an empty spot in a busy measure.)
When you right-click an element that belongs to a particular measure—that is, a note or a rest—then you get Staff Properties and Measure Properties as a convenience, inserted above the note or rest menu.
But right-click an element that can affect or cross between two measures or staves—a slur, a time signature, even a beam—and you see a menu only for that item; Measure Properties and Staff Properties don't appear. Too much of the time, MuseScore wouldn't be able to tell which particular measure or staff you were trying to choose.
I'd support a user option to have the full staff and measure menus appear when you right-click a note or rest, instead of just the two Properties items.
I'd also support having Measure Properties and Staff Properties added to the popups for elements that are bound to a specific single note or rest, such as stems, lyrics, and dynamics, but I don't think those menus could be easily applied to other element types.
In reply to I don't think of Measure by Seamas
Regarding insertion of elements: Again, I don't dispute that they can be inserted either above or below. The problem to me is that it seems not to be consistent behaviour.
I guess the real problem is that it is hard for MS to know which particular aspect one is addressing, and location is the only way it can guess.
For me, when I am doing these operations, I generally am working on at least one page and so the areas shrink.
Thanks for the info on why it happens - I can try to be more precise.
I'm not quite understanding. Are you saying the dialog itself is positioned differently from one time to the next? I don't see this on my system. Measure Properties is always dead center. Even if I move the dialog, the next time I open it it is dead center. Staff Properties, on the other hand, always opens at the last location it was moved to. Are you saying you are seeing soemthing different, or are you talking about something else? Could you post screenshots showing what you mean?
EDIT: oh, maybe I understand. You are talking where the item "Measure Properties" appears within the context menu. I don't know that there is a way to make it always appear in the same place for every possible element type. Well, we could probably do that, but then some *other* menu item that is common to several element types wouldn't be int he same place. The only way to have the same position for all menu items would be to have the exact same menu for all elements, but then it would be huge, and would defeat the purpose of having the contents of the menu depend on the type of the element you clicked.
In reply to I'm not quite understanding. by Marc Sabatella
Fair enough, but anything that contains the same elements should be standardized, don't you think? I still can't see the logic in changing common menu parts depending on external factors.
In reply to Fair enough, but anything by xavierjazz
It's ahrd to explain, but let me try with an example. Consider the following lists:
A
B
C
D
E
F
G
----
C
G
----
A
D
E
F
G
X
Y
Z
----
G
Z
Can you see any eay to arrange these lists so that everything that is common between multiple lists is in the same place in each of them? I'm pretty sure it just isn't possible.
That said, there may well be ways to improve the consistency somewhat over what is the case now. It would probably take someone going over all the different contexts menus, really looking at what is common between what elements, and coming up with a good overal strategy to try to minimze the number of unavaoidable inconsistencies. Could be an interesting project for someone...
I think based on your initial description, the problem here is that sometimes you are right clicking an empty spot in a measure and other times you are clicking an actual element. Taking care to always click an empty spot would be a good habit to get into, although sometimes that is easier said than done.
In reply to It's ahrd to explain, but let by Marc Sabatella
I understand.
As to where I was clicking, I was always trying for a blank space, but as we know often elements have a larger footprint than visible. This reminds me of another small peeve which I will post as a request.
"That said, there may well be ways to improve the consistency somewhat over what is the case now. It would probably take someone going over all the different contexts menus, really looking at what is common between what elements, and coming up with a good overal strategy to try to minimze the number of unavaoidable inconsistencies. Could be an interesting project for someone..."
Perhaps. When you say "context menus", can you please explain just what they are so I could at least consider such a project? Are they all things that are accessed via rt. click?
In reply to I understand. As to where I by xavierjazz
Yes. The technical term is "context menu", because the contents of the menu depends on the context (eg, where your mosue is when you right click), also because they can be accessed by ways other than right click (not so many people actually use mice, or have two separate buttons, any more).