Eliminating right click access to the remaining properties
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
I'm interested in this "button" idea, could you explain more of how it was discussed on Telegram?
In reply to I'm interested in this … 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 I support seeing the… 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 Preferring the context menu… 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 All I'm suggesting is that… 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 I have no problem with… 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.
In reply to I support seeing the… by Marc Sabatella
I'm now focusing on a comprehensive way to include these option while also decluttering what's there right now. Will share soon. Might be an idea to set up a call to go through at some point.
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.
In reply to If you ask me, I want to do… by Howard-C
Yes, one by one is just fine
In reply to Yes, one by one is just fine by Jojo-Schmitz
If I don't get this wrong, inspector UI and right-click prop use very different code systems, so even though it isn't very hard, it can still be a bit troublesome...
Section Break Properties is moved to Inspector in https://github.com/musescore/MuseScore/pull/5462.
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.
In reply to I wasn't familiar with S… by Howard-C
If the style is connected properly, and the rest button created properly, the set as style button should show up automatically (in InspectorBase::mapSignals).
In reply to If the style is connected… by Marc Sabatella
Sure, but I didn't connect the property and style when I opened that PR. If S button is truly needed then I'll connect them.
In reply to Sure, but I didn't connect… by Howard-C
If there is a style, there is no reason not to make the property styles. Then the button takes care of itself.
In reply to If there is a style, there… by Marc Sabatella
OK, S button is added.
I've been gazing at the conversation between @Marc Sabatella and @mike320 but am not able to draw a summary of what's most preferred by the majority of users, so could either of you please give me some general yet clear hints of how to improve this?
If you ask me, I think the way bend properties is now is a good idea, having suitable-for-inspector settings in the inspector and UI-complicated ones in a separate dialog, the dialog can be brought up both via context menu and inspector.
In reply to I've been gazing at the… by Howard-C
Some of the properties can easily be put into the inspector, like Bend properties. It's very similar to fretboard diagrams so that seems a no brainer to me. Section break properties is another that seems a no brainer to me to put into the inspector since it's only a few fields and check boxes.
Properties like Staff/Part Properties are a bit more difficult to simply put into the inspector. Questions need to be answered like
When can you access the properties? (in other words, what do you click that allows you to access the properties and if it's only a button in the inspector, what does clicking this button do? It could very well simply bring up the current dialog box).
Which properties could stay in the inspector? (this means they could be applied to several staves at once)
There are other questions that would need to be answered for design purposes and similar ones would exist for measure properties.
Since Style and Page Properties are accessible through the main menu, I wouldn't worry about putting those into the inspector. Most or all other context menu items that are also in the main menu are not in the inspector.
In reply to Some of the properties can… by mike320
I don't use fretboard diagrams but I happened to see how they work in @Tantacrul's video, so you mean bend properties should be moved to inspector the same way as fretboard diagrams?
In reply to I don't use fretboard… by Howard-C
That is my opinion. From my limited use of both of them, it seems the interface is similar enough there should be no reason they shouldn't both be in the inspector.
In reply to That is my opinion. From my… by mike320
OK. I will see if bend properties can fit into inspector without being too wide. I mean, I hadn't cared to compare them before this topic was brought up.
In reply to I've been gazing at the… by Howard-C
Bend properties makes sense, but it's a relatively complex interface, not just simple standard controls like almost everything else in the Inspector. Not sure how easy it will be to move it, but if it's not too hard, I definitely agree it's a good idea. But again, just putting a button there to popup the dialog is an improvement, as it makes it more discoverable than right-click.
Staff Properties and Time Signature properties are likely more complex than it's worth, but buttons could work for those too.
In reply to Bend properties makes sense,… by Marc Sabatella
I have a concern, which I have expressed before, but I don't think it's on anyone else's radar... which leads me to think that I'm mistaken in my thinking. So, I'll say it again here, and someone can explain to me how I'm mistaken, and we can forget that I was interrupting.
If I right-click on an element, opening a dialog box to edit it, the Apply or OK button combines all operations in that dialog to a single undo step. If I edit something via the Inspector, however, each increment that I add to a value becomes a separate undo step. If I don't like the result of an edit, I must undo each individual value that I edited in the inspector. This makes the undo function confusing and time consuming for anything other than quick edits. Heaven forbid that I might want to go back and undo a PREVIOUS edit. I thought at one time that the screen would snap to the position of the last undo step, but I must be mistaken.
Speaking of mistaken, someone please explain to me that I'm way off track here. As I said, no one else seems to be concerned with this, so I must be making some incorrect assumptions here.
In reply to I have a concern, which I… by toffle
To me, you just described a great benefit of the Inspector - the abiltiy to undo individual settings rather than forcing it to be all-or-nothing. If you happen to do several adjustments in the same sitting, sure, it takes a couple extra seconds to undo them all - but how often would that come up in real life? Why bother making several different adjustments then decide you don't like any of them?
In reply to To me, you just described a… by Marc Sabatella
Ok, I’ll give you an example...
Sometimes it takes a good dozen clicks on the x/y buttons in the inspector to get something where you think it fits. You do a couple more edits and then realize you have a wrong note or time value, or the auto position relationship between item A and item B are now out of kilter because of item C.
If the A, B and C adjustments registered as single-click edits, you could easily toggle back and forth between values, but now, there’s a dozen (or several dozen) increments stored in the undo chain. Sometimes resetting an item in the inspector works, or sometimes it complicates things. In either case, this is adding steps forward in the undo chain. If I want to undo an edit to item A, I’m probably better off deleting and re-entering it than trying to reach the previous state via undo.
In essence, the more the undo functions as an increment tool, the less effective it becomes as an “event” tool.
As I said, I must be thinking of this wrong, and am likely overlooking more effective editing techniques if I’m relying on undo to be useable on more than one or two events.
In reply to Ok, I’ll give you an example… by toffle
I would say clicking the arrow buttons is only for very fine adjustments. For coarser adjustments it’s more efficient to use the cursor up/down keys on your keyboard, either in the spin box or by using Ctrl plus cursor tp move the element directly. It’s of these actions move in larger step values.
But also, to reset a value, no need to undo repeatedly, just press the Reset button next the control, or use Ctrl+R to reset multiple values at once.
In reply to I would say clicking the… by Marc Sabatella
The point of the is that if you make any adjustment whatsoever to one of these fields, every character is undone individually. For spin boxes if you type a value like 5.36 undo once will change it to 5.30, again makes it 5.00 undo again finally returns it to the original value. That's not terrible, but if you change the text on a text line to
poco------a------poco------cre------scen------do (where each - is a space)
undo affects one character at a time. So if what you want to undo is the paste operation you did right before this edit, you now have to undo 49 times!
In reply to The point of the is that if… by mike320
For regular text edits, we handle that as a special case, combining all edits made in Edit mode into a single undo record. The combining happens when you leave Edit mode (and this happens to be exactly why changes made in the Inspector while editing gets lost - their undo records can't be combined with the others). In principle, the same approach for edits to text within the Inspector could be used here - the combining could happen when focus leaves the edit field.
In reply to For regular text edits, we… by Marc Sabatella
That would be the ideal situation. The ability to undo while editing an item then the ability to undo the entire item with one key or button after edit.
In reply to Ok, I’ll give you an example… by toffle
@toffle : if it is of any help, I completely agree with your concerns and I also feel nobody else seems to care about a very arguable decision.
I didn't like the inspector when it was firstly introduced years ago and I still mostly do not like it; it is probably convenient for some kind of edit, but cumulatively it is more a curse than a gift, in my opinion. I also notice that nobody really answered your basic question(s?) to mostly elaborate on minute details instead.
In reply to @toffle : if it is of any… by Miwarre
Hmm, I answered the portions I understood. To be honest, I'm having trouble understanding any possible sense in which anyone could dislike the Inspector, especially compared to what came before it (a modal dialog that required extra keystrokes to display, didn't update the score in real time, and had no facility to transfer settings to the style). So you might need to back up and give the picture of your objections, because they are completely foreign to most of us.
In reply to Hmm, I answered the portions… by Marc Sabatella
To be absolutely clear, I like the Inspector. I use it every day, and I appreciate the wealth of information and editing capacity it provides.
My concern, (which I believed was clearly stated) was that incremental edits, as necessitated by the Inspector, have rendered the undo function ineffective. In the past couple of days, I have done two specific "tests" of the use of undo in relation to incremental edits via the inspector. In the one test, I performed a number of edits via the Inspector, and then used undo to reverse those edits. The result was somewhere in the neighbourhood of 100+ undo clicks to return to a previous state. (100+ clicks, but only a handful of "completed" functions.) The other test was to do a similar series of edits, after which I deemed it (much) more expedient to simply close the score without saving and re-load the score which was saved at an earlier stage. You can't possibly tell me that an editing flow that favours abandoning a score over being able to undo a few completed steps is preferable for the development of this software.
In reply to To be absolutely clear, I… by toffle
I do feel I understood your original concern and responded to it: to me, being able to undo separate settings made with separate individually is a great thing, but I do agree that it might be nice to collapse consecutive changes made in a single control. What I am then confused by is the suggestion elsewhere that somehow I missed the main point and that we were "mostly elaborat(ing) on minute details instead".
BTW, I am having trouble imaging a real-world scenario in which you'd literally do 100 operations in the Inspector and then need to undo them rather than just reset. So I think the tradeoff you are suggesting - between abandoning a score vs holding down Ctrl+Z for longer than otherwise - is rather artificial. I think that failing to recognize the very real benefit of having independent undo doesn't contribute to the discussion, because that is the real tradeoff. Independent undo vs fast undo.
To me, the sweet spot is in keeping the individual controls independent but collapsing the consecutive steps within a single control. But - another option is to simply expose the undo stack, so you can select how far back you want to undo. Make this a tree structure so the consecutive changes to the same control appear as one until you expand it, but allow you to expand so you can actually undo partially as well (useful if, say, you overshot the desired result when incrementing - you want to undo that control only partially).
In reply to Ok, I’ll give you an example… by toffle
Attempting to look at this in the original context, I guess the claim is a dialog would better because then it wouldn't take several undos to back out of a bunh of incremental change. But the modal properties dialogs don't update in real time, so the whole notion that you might be incrementally changing a value until it looks right doesn't hold water - that doesn't work at all. So it's not like that use case works out better with modal dialogs. Quite the contrary - with them it takes ten times longer just to get the value the way you like it to begin with. I'll take slightly slower "undo" (press and hold Ctrl+Z instead ot just one press) over much more difficult "do" (a frustrating and finger-twisting exercise in opening a dialog, trying a value, hitting OK, checking the result, and repeating until you like the result).
So yes, I'm really having trouble understanding the objection. I get that maybe it could be made even better if we collapsed changed to a single control into one undo record - but the current situation with the Inspector is hardly makes this worse than the incredibly painful-to-use modal dialogs it replaces.
In reply to Attempting to look at this… by Marc Sabatella
ok
i hear you
i remove myself from this discussion.
In reply to Bend properties makes sense,… by Marc Sabatella
Hi! I've begun moving bend properties into inspector, my progress can be tracked at: https://github.com/Howard-C/MuseScore/tree/bend-properties.
In reply to Bend properties makes sense,… by Marc Sabatella
PR created at https://github.com/musescore/MuseScore/pull/5518.
I didn't expect to be this quick ;-)
Is it really necessary to still move parts of Time Signature Properties into the inspector? Technically, the "Values" and "Appearance" sections can be moved, but leaving only the "Note Groups" section in Properties dialog... doesn't feel right...
But I'm totally in favour of a "Properties" button just like the one in bend inspector (which will be replaced in 3.4, so R.I.P.).
In reply to Is it really necessary to… by Howard-C
I'd rather see all the properties remain in one place. A button in the Inspector is fine. But FWIW, I prefer that for anything that still has a separate properties dialog, it should be accessible both from the Inspector and the right-click menu.
In reply to I'd rather see all the… by Marc Sabatella
This is probably a silly question, and I haven't been following this thread as diligently as others, so forgive me if I'm way off base here.
Where do the selection filters go if you are eliminating right-click access? (I haven't seen this in the discussion threads) Currently, if I want to select all tempo change events, I right-click on any tempo marking and select "all similar events". Will the selection filter be added to the Inspector? Will selection filtering become any easier (once we've become accustomed to the change in procedure) without right-click access?
If I'm being absolutely daft here, don't hesitate to let me know. I have no objection to learning new ways to do things.
In reply to This is probably a silly… by toffle
Actually, we're only talking about those right-click properties windows here, like (former) Section Break Properties, Bend Properties which have already been moved to Inspector in 3.4 beta. And the word "eliminate" is not very accurate though, because if some properties windows are too massive to move to Inspector, we want to keep the right-click access but also add a button in the Inspector which can also bring up the window once clicked.
It's not impossible to also move the selection filters, but apparently not everything can go to the Inspector, because then it'll be too clustered to read. An apparent advantage of moving something to the Inspector is that you can select multiple elements and apply changes/buttons at once, but with selection filters, do you really need this? I don't think I need it.
In reply to Actually, we're only talking… by Howard-C
Ok, thanks. This is good to know. I suppose there's little point in de-cluttering one tool at the expense of adding clutter to another. Do you know if the selection filters will still be called via right-click, or will there be some other way of initiating the process?
In reply to Ok, thanks. This is good to… by toffle
I didn't say they will be moved. In my opinion they can stay in where there are now.
In reply to This is probably a silly… by toffle
On the side (toffle): Just in case you missed it, in preferences->shortcuts there is also a definable keyboard shortcut for the vanilla "select all similar" filter. If you're more of a keyboard user, this can be slightly more convenient/faster than using the mouse under certain circumstances.
In reply to On the side: Just in case… by worldwideweary
But what's most useful is "select all similar in range selection", can I define a shortcut for that?
In reply to But what's most useful is … by Howard-C
Sure, but it doesn't make any sense if it's accessed through the keyboard. After range selection, how does one select the desired 'type' of element with the keyboard without losing the range-selection? If one resorts to right-clicking an element, it appears to negate the purpose of a [select all similar in range selection] keyboard shortcut.
In reply to Sure, but it slightly doesn… by worldwideweary
Right, you got the point there.
In reply to Right, you got the point… by Howard-C
Three or so months ago I started a thread about this, and the idea of 'freezing' range selection came up: https://musescore.org/en/node/295051
To keep an overview, see also #118086: Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3.