Eliminating right click access to the remaining properties

• Nov 1, 2019 - 14:14

A discussion of moving things like score properties was started in #292343: Measure numbers restart from 1 after section break even if the corresponding property got disabled. The discussion belongs here in the forums rather than hidden in a remotely related bug report.

Recently there was a discussion on telegram concerning moving the remaining properties windows from the right click menu to the inspector. The discussion suggested that for some properties, like staff and measures properties, a button could simply bring up the existing or a similar properties box as needed, while putting any appropriate properties into the inspector. The discussion was vague, but it was a good discussion. Continuing it here and perhaps having someone committing themselves to fixing this for 3.4 or 3.5 would be a good idea.


Comments

In reply to by Howard-C

The discussion was probably about a week ago, so I don't remember everything. The basic idea is to add a "Properties" button (similar to the Note, Rest and Grace notes buttons) that would open a new window. Most all of the properties currently in the various properties windows would stay there, though the occasional exception might make sense. For example, I don't see the option to make measures stemless or invisible in Measure Properties being put into the inspector. It might make sense to make a dialog box that will only do this though rather than integrating it into a larger dialog box as is currently the case.

With the proper code, this would allow the user to change the actual durations of several measures all at once. (I'm thinking with my keyboard right now). The main reason you would want to do this is when the key signature says alternate between 9/8 and 6/8 and you want to change every other measure to 9/8. Unfortunately there is no list selection for measures.

An exception was mentioned. Section Break properties could easily be place in the inspector and the dialog box eliminated.

I support seeing the remaining properties moved to the Inspector - ideally, with direct settings where that seems feasible (section break properties, mostly I guess). But I'd also note that for accessibility purposes, the context menu is potentially an easier place to reach these from, if the context menu were properly accessible (see #296416: Context menus not accessible). Other possibilities include making these commands that can have shortcuts assigned.

What else is there? Here's what I can think of:

staff
measure
time signature
staff text
section break
change instrument (command)

In reply to by Marc Sabatella

Preferring the context menu in some places and not others does not make sense. Consistency makes more sense, especially to a blind user.

I suppose that measure and staff properties are still in the context menu because there is no obvious place to click and get measure properties, then another place to click and get staff properties. Currently, you can usually right click a place and choose either option. With the button idea, one button could lead to measure properties and another button would lead to staff properties.

Marc also mentioned the page settings property being the default inspector view since that's the option you get when you right click the empty paper. There are also System text properties (like swing).

In reply to by mike320

All I'm suggesting is that we don't lose these options. We can certainly add the equivalents for other elements that have separate dialogs, for consistency. The idea being for things you can actually do in the Inspector, then sure, using the Inspector makes sense. But for things where the Inspector is just a way to get at a separate modal dialog, we should continue to provide a more direct way to access the dialog. Having the button in the Inspector is good for discoverability, having them in the context menu is good for usability/accessibility, having all of them in the same places (whether all in Inspector, all in context, or - as I'm suggesting - all in both) is good for consistency.

And yes, the Inspector when nothing is selected is a good place for the things currently in the context menu when the mouse is not over anything.

In reply to by Marc Sabatella

I have no problem with properties being accessible through context menus, I was leery when most of them were removed. However, the benefit of being able to apply a property to multiple elements made me like the idea more. I like consistency. Find a way to do one thing and use the same method to do similar things. This makes new functions more discoverable, which is what many of these changes that have already been made are related to.

An example: I understand why staff properties are currently in the context menu, but so many other items are only in the inspector. I previously used the context menu and know of the existence of the properties, so I know to right click to find the properties if they do not appear in the inspector. A new user starting in version 3.0 (or 3.3) would not have that experience and discoverability becomes more difficult.

From a user's point of view, I would prefer more things in the context menu. This is because access to everything is right there. If I have my mouse in hand, I might as well use it. I stack my inspector, palettes and filter windows so I access them by tab rather than keyboard shortcuts. As a result, I prefer to keep the palettes open since they often require mouse interaction to use an item. Anything I can access by right clicking means I don't have to change to the inspector then back to the palettes when I'm done. It's just my workflow and probably will not result in any changes I prefer. As I said, from a development point of view consistency is most important.

There is something that would improve my workflow and make sense that is tangentially (or maybe totally) related. When you use a shortcut to close a window (like palettes) then press the shortcut again, focus is not put on that window. It remains on the window it was previously on. If they're tabbed, the newly opened window is not given focus and you are forced to click the tab to tell MuseScore that you opened it because you actually wanted to use it.

In reply to by mike320

Being able to apply properties to multiple elements from the Inspector is nice indeed. I wouldn't assume that merely putting a button in the Inspector to open a dialog will magically give the dialog that capability, though, so we'd have to be sure to think that through.

Regarding focus on opening a window - palettes actually do that, at least in 3.3. But the Inspector doesn't nor do other non-modal windows (windows that don't completely steal all focus). Recently somehow was just complaining that the 3.3 palettes do...

Tab & Shift+Tab will generally move focus between the score, the palettes, the Inspector, toolbar, and any other windows. Usually from the score, Shift+tab goes to the palettes, or tab goes to the Inspector.

BTW, bends are another thing that has its own properties dialog now.

If you ask me, I want to do this one by one. I will get my exams done by Friday and therefore I can try to move the Section Break Properties.

I wasn't familiar with S buttons before, but I messed around with it recently and came to realize, shouldn't the "pause" property of section break need an S button? Because there's an existing score style connected.

Do you still have an unanswered question? Please log in first to post your question.