Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3

Just a thought: It may be actually be more convenient (and comfortable?) for the user to use a custom-positioned/sized properties dialog rather than the Inspector—which is longer, narrower, located on the edge of the window, and may require scroll bars.

Now you have the Inspector sitting in the middle of your score rather than on the side. :(

Which is just what a dialog would do as well, except the Inspector has the advantages of being toggleable with a single keystroke, also it is non-modal so you can continue to work with it up if you like. It is superior in every way to a modal dialog.

As long as there's no scrolling involved. The length of the Inspector can be an issue, making it necessary to scroll down to get to some properties.

I am not clear on whether this proposal would put the text-editor itself into the Inspector. If that is indeed what is being proposed, it would seem to raise a question about ease/rapidity of access to the text editor. While I like the idea of having more properties editable directly in the Inspector (although I can't yet visualise how the UI would look), I would definitely not want this proposal to eliminate the ability to open the text-editor with a double-click on the text element.

Would it be possible to have the Inspector pop up on a double click, the way the present text-editor does? Also, to be able to hide it again with a click on a blank part of the score would be good.

My reasons for asking this: To use the Inspector it obviously has to be open, but it does occupy a fair amount of screen real-estate no matter where the user docks it. The user can resize it to occupy just a small corner, but then scrolling becomes an issue, as Geetar mentions. For instance, when using the mouse wheel to scroll, one must ensure that the cursor does not wind up over any of the scrollable menus, or the different choices for that parameter start to scroll through the menu instead of the Inspector window itself moving up or down.

I don't keep the Inspector open on my screen while working unless I have a specific need to adjust the properties (usually the offset or height) of a particular element. As Marc points out, it's easily toggled on/off with a single keystroke, but it would slow me down to have to open the Inspector just to gain access to the text editor for reformatting typeface, font, and size, etc. Presuming I am already using the mouse while editing a score (the usual case), the traditional 'double-click' on a text element is faster than lifting my hand from the mouse to type F8 and then returning it to the mouse to hover and click on the appropriate field in the Inspector (and then reversing the process when I am done with whatever edit I was doing).

In sum, anything that requires extra arm/hand movements is less than ideal. Users often have three distinct keyboards in front of them (midi keyboard, numeric keypad, computer qwerty) plus the mouse. Every hand shift from any one to any other slows down the work flow.

Thanks for the clarification. That being the case, would it make sense to you to add the Inspector to the right-click menu? It would help keep hand-shifts to a minimum, I think.

Would the "bend properties" dialog be suitable for putting in the Inspector? And +1 to fretboard diagrams in the Inspector.

Indeed, and infortunately :(
I disagree on the term "take care" of voltas.
The Volta Properties have moved now into the Inspector.
There is no more the ability to open these Volta properties via a right-click onto the score. I regret this.
For my use case, the Inspector is never open by default, occupying a fair amount of screen (noticed by other users in previous comments). And above all, you loose the ability to remain on the spot :(
It is not pleasant, if not tiresome, to multiply movements inspector-score, score-inspector, x times, and so one for each score.
Furthermore, anything that requires extra arm/hand movements is not good and slows down the work flow.
Clearly, there are two "schools", with opposite (or different) use cases. For my part, I prefer, without common measure, remain on the spot. Or at least not to be deprived of this, as is the case now with these Volta properties.
So, we have to reconcile the two approaches, or to keep the two approaches. The term "eliminate" should be avoided; to have the choice should be promoted.
Move these properties in the inspector, why not, for those who prefer. But do not remove the ability to access to the properties via a dialog onto the score with right-click for those who prefer.

I agree with Cadiz. It is always unpleasant to see a very simple operation be ruled out for either bidder improvement rather questionable (like Cadiz inspector is only open when I can not do otherwise, or for batch processes) and especially it is even more unpleasant to be imposed on a type of operation. One of the reasons that I came to MuseScore (0.9.5) was its flexibility allowing to have ITS ergonomics and redundancy controls in many forms is imperative for this. integrate the inspector: Yes, but keep in popups and menus.

"especially it is even more unpleasant to be imposed on a type of operation."
This is the main point of my thought too. Thanks for your support Miré :)

If I sum up the concern of cadiz1 and Miré:

1. We loose the ability to go to properties from right click. Now we need to have the inspector open or to open it via menu or keyboard shortcut. I guess that would be easily solved with an "Inspector" or "Properties" item in the context menu? Also there is current no way to close the inspector with the keyboard.

2. Properties being in the inspector, we now have to move our eyes to the inspector panel instead of having the dialog right in our face. A possible solution is to undock the inspector and put it in the middle of the screen. Unfortunately the inspector layout is really hardcoded to be a vertical rectangle.

The first point is not really a problem (for me). I do: right-click in an empty area of the toolbar, and tick/untick Inspector very quickly.

However, the inconvenience (and a regression, in my opinion) is the second point, indeed:
"2. Properties being in the inspector, we now have to move our eyes [(and arm/hand movements)] to the inspector panel instead of having the dialog right in our face."
Undock the inspector? A priori, I am circumspect about the result, and the work flow. And so, difficult to be hard coded.

So why not keep the context menu? In others words, why exclude one (Properties in the context menu) for another (Inspector)? I have difficulties to understanding this.

@ Nicolas:

Also there is current no way to close the inspector with the keyboard.

I must conclude you are describing the proposed new behaviour, in the 3.0-development versions? If that is correct, I would strongly suggest that that be changed back to the toggled (F8) behaviour currently available in 2.0. I suggested adding the inspector to the context menu, so I obviously agree with that; I also suggested being able to close the inspector by (among other methods) single-clicking a blank space in the score. However, I still think having the ability to toggle the Inspector on and off using F8 (or whatever keyboard shortcut one prefers) is important. There are many different kinds of work situations; the program should take as many of these into account as possible.

My mistake, F8 still toggle the inspector on and off. I was trying with Esc or Ctrl+W.

@cadiz1
Having both the dialog and the properties will not work. We don't want to have 2 places in the code to change when we add a property or fix a bug. That's the best way to create even more bugs. So let's try to find a creative solution to the problem of moving our eyes to the inspector panel, docked or not.

In this case it is the ergonomics of the inspector must be reviewed. For example, to act on the notes I have all the options displayed: Elements, Segments, Agreements, Note, Selection. All this is deployed would it not possible that the inspector is a list of features that are deployed is useful to us: saving space, and in this case, the integration of the selection filter (which I have already requested) makes sense. Which would give it the appearance of a context menu. With the inspector and the selection filter open I can not see my score (why I rarely use more I use the inspector) I must alternate between them. As said Cadiz ... I lost a lot of time. Incidentally with version 1.3, even spending much time to "play" the ornaments I almost was writing my scores faster ... that's how the inspector for useful it before integrate new functions to it, must be made more convenient and certainly less cumbersome ...

@Nicolas--Ah, good. And yes, I agree, I am frustrated when I try to close the Inspector by hitting ESC, which happens often enough. Because that single keystroke closes all (?) the dialogue windows, it's a learned reflex action and when working at speed, the fingers move faster than the brain (just as with fingering an instrument). ;o)

@ Cadiz--Nicolas' reasoning for not keeping right-click-accessible Properties dialogues and having those same Properties dialogues integrated to the Inspector makes good sense to me. (Imagine if you had to remember to change each part individually whenever you edited a note in a score?) But unless you're running a much larger screen than most non-developers need--something bigger than the 24-inch class--I don't see a problem with having those properties displayed in the inspector in its default docked position on the right edge of the screen. It isn't really that far away from 'center-stage', a couple of inches at most on a wide-screen laptop. Remember, eyes move much faster than hands/arms, and with much less muscular effort, too, due to the much smaller mass involved.

The only question for me at this point is what the UI would actually look like. The Inspector is already so full of options for most elements that I have to scroll to see them all; adding a whole new properties dialogue section to it would, it seems to me, require a complete redesign. If that job fell to me (the graphic design, I mean; not the code itself, which I am incompetent to touch), I would probably do something along the lines of collapsing each section of the Inspector, similar to the way the F9 Palettes list is presented. In fact, I don't see any other reasonable way to do it given the space available.

Actually you are correct. It is when a note is selected that the Inspector is jammed full of stuff. When a text element is selected, about half of the panel is blank right now. But if your idea is adopted, all the parameters currently in a Text Properties dialogue--Face, Font, Size, Vertical and Horizontal Alignment, Vertical and Horizontal Offset, Colour, and Frame, as well as the special properties that pertain to things such as Tempo Text, Dynamics Text, and so forth--will have to be put into that area, and that will require some space management. I do think that telescoping things into expandable categories is going to be the best way to go. It will also contribute to a consistent look and functionality of the UI.

I like your mock up. It resembles the Palettes list, which is a good model to follow as it is quite functional, and there is even an option (which it took me some time to discover) to close any expanded category automatically when a new one is clicked.

We might also, in a different context, want to examine re-naming some of the categories so that they are more 'user-friendly'. Names such as 'Element' or 'Element Group' are more meaningful to programmers than to average users.

When you change a property in the Inspector, the score is instantly updated. But is this appropriate for all features such as a fretboard diagram or a bend? Isn't an "Apply" button (in a dialogue box) best in these cases?

@geetar--I think I understand your concern, but I also think it would work out okay without the 'Apply' button for most things. When I am experimenting with placement or sizing of something using the Inspector, I type in the offsets or frame heights and hit 'Enter' to see the result. (Or, I can alter the offsets or heights incrementally with the arrow buttons on those fields and see the changes happen 'live' as I do that.) If I don't like what I've done, I simply overwrite my last try and hit 'Enter' and the score is updated again. IOW, the 'Enter' key functions as the 'Apply' button would, executing the changes but keeping the dialogue open.

What might be nice, OTOH, is allowing an 'Undo' command to revert the last change while the Inspector is still open. Currently, one has to close the Inspector first, then hit CTL+Z. If I have started with an odd offset or frame height, altered it, and then don't like it but don't remember what the original figures were, Undo is the best option.

Are there specific parameters for fretboards or bends that you think would not work when treated in that manner?

I assume that when the Inspector is selected from the context menu, focus changes from the score to the Inspector. So arm / hand movement issues should be taken care of.

I don't know if I like this idea, but perhaps when selecting Inspector from the context menu, a dialog animation can show a frame outline moving and growing from the active spot in the score to the frame of the Inspector, whether the Inspector is already open or not. That would drag eyes to that spot.

I can see that the Inspector is ideal for altering alphanumeric properties. But what about "graphical" properties: e.g. Adding/deleting finger dots, barres, etc. to the Fretboard diagram, or adding/deleting points to the Bend graph?

If the user tries to open the Inspector via the right click context menu when it is already open then maybe it could wobble or there could be some kind of animation to draw attention to it.

Sorry, friends, but I must register a strong objection to putting any sort of animation into the program. There is nothing in computer-dom that is quite so annoying as being forced to watch some "cute" video effect over and over and over and over and over again.

NOT FOUND: !

@geetar--

I had never used either bends or fretboard diagrams before, so I played with them a bit this morning. I can see that working with them is an entirely mouse-driven activity, and that right now it is a pain just to get edit-access to them as you have to go through the right-click menu. I would vote for having a standard double-click open the Inspector with the Fretboard (or Bend) Properties displayed so you could edit the element right away. (Just like the 'Lines' properties we were discussing earlier.)

I do see where you might want an 'OK' or 'Apply' button to avoid having to move your hand off the mouse and over to the keyboard and back. OTOH, it seems to me that the Inspector could be set to update a fretboard or bend diagram in real time, as you made changes to it, so that no 'Enter' or 'OK/Apply' would be needed.

@Recorder485, your animated GIF is certainly annoying because it is a pointless animation and it is on a loop. However, a one-off animation is a valuable tool for attracting attention - and in the example I suggested it would be educational rather than distracting. The "wobble" would last for a fraction of a second and it would simply draw attention to the fact that the Inspector was actually already open when the user requested it. If you already know what the Inspector is and how to use it then you would never see the animation because you would never try to open it if it was already open. Also, the wobble was simply a suggestion, it could blink, glow or even just close and immediately open again. The effect could be quite subtle (but not too subtle for obvious reasons).

That particular GIF has been around for many, many years, and it is actually funny...but for a very limited period of time (say, about ten seconds or so?). After that, it becomes seriously annoying and if it were embedded in a web-page or a program, users would not suffer it gladly.

The thing to keep in mind when proposing anything of this sort is that while it might be innocuous (or even amusing) the first time it shows up, it quickly becomes a problem after that initial exposure.

It's not one instance of that 'wobble' that you propose (or the 'expanding frame' proposed by Jim) that is problematic; it is the repeated behaviour every time a user executes a certain command. If anything like this were to be included in a future version of the program, I would demand that an option to turn it off were offered. Even Microsoft—which routinely panders to the lowest common denominator among computer users (and doesn't listen to them unless forced to do so)—offers a way to turn off that idiotic animated paper-clip 'Office Assistant' of theirs. MuseScore is better than that, I hope.

I am not a four-year-old who is impressed by visual flashiness and cutesy graphics...and I don't want the programs I use to treat me as if I were.

Sorry, I don't mean that to offend anyone, but I have to say what I think and that's the way it looks from here.

I wasn't offended and I was the guy that suggested the moving / growing frame. Which I also commented I wasn't sure I liked the idea.

But I think it did generate a useful dialog. And I appreciate the comment of don't use animation needlessly.

My current thinking after reading the comments is generate *some* visual cue when activating the inspector from the context menu, even if it is already open. If the inspector is opened via the context menu that should be visual cue enough. One more subtle approach might be to make a change to the frame of the inspector window without movement. It could darken and quickly go back to normal, for example. Or thicken, or both.

BTW, I'm not sure *exactly* what "wobble" means. Does it mean moving the position back and forth? Or wiggling like jelly? That latter could be hard to implement. The former, should be fairly easy (just a Qt dialog box property, I assume).

I wasn't offended and I was the guy that suggested the moving / growing frame. Which I also commented I wasn't sure I liked the idea.

But I think it did generate a useful dialog. And I appreciate the comment of don't use animation needlessly.

My current thinking after reading the comments is generate *some* visual cue when activating the inspector from the context menu, even if it is already open. If the inspector is opened via the context menu that should be visual cue enough. One more subtle approach might be to make a change to the frame of the inspector window without movement. It could darken and quickly go back to normal, for example. Or thicken, or both.

BTW, I'm not sure *exactly* what "wobble" means. Does it mean moving the position back and forth? Or wiggling like jelly? That latter could be hard to implement. The former, should be fairly easy (just a Qt dialog box property, I assume).

I don't see it as moot. I am assuming we are talking about the scenario in a future version 3.x that choosing "Properties" from the context menu normally sends you to the Inspector. If the Inspector is closed, it will open so that should be obvious.

But if the Inspector is open, and a new (or infrequent) user under v 3.x selects Properties from the context menu, what's to let them know they should look to the Inspector?

By the way, under that scenario, I don't like the idea that the context menu actually has "Properties" as the choice, and being sent to "Inspector" as the dialog box.

And I don't know whether I like the idea of "Inspector" as the choice on the context menu. Would that mean much to a new user?

Layout break properties, esp. for section break, is another candidate to get moved to the inspector, maybe something like this:

Probably should be disabled if it is not a section break.

Another one seems to be Tremolo bar properties

lasconic mentioned on IRC today, that it would be good to convert the whole inspector into a treeview widget

I like your collapsible-sections idea. It would really make for a versatile tool.

As far as speed menu v. inspector is concerned, I am a late comer to the discussion. I don't like having to remember that I have to right click cresc. to change the text but F8 to get the inspector to change the note head. I have a preference for the inspector for all things because of the default F8 hot key. It also lets you modify multiple (unlimited?) similar elements at once as opposed to the speed menu which limits you to a single item at a time. When I want to change "cresc." to "poco a poco cresc." on all 35 staffs of the score I have to make 35 changes and not 35 clicks (which are necessary anyway) and 1 change. Of course if there were an internal flag that changed "cresc." to a system text rather than a staff text when you applied the velocity change to the system that particular one would not be an issue, but I digress. There are many hairpins that are never applied to the system.

As far as the inspector getting in the way, the inspector window can be ignored and move wherever the user wants to put it. I usually keep mine undocked so my display is wider and I move it out of the way if I need to see what is under it. When I'm not actively editing with it I press F8 again and it disappears. I can easily change the size of the inspector window if I prefer and scroll through the options if needed or enlarge it so I can see all of the options I want. The ability to change size of the "Line Properties" window for example is very limited.

If all speed menu options went away (besides the standard ones on every application) or were also available on the inspector I would be happier with this fine tool.

I believe many other applications take that very approach

If that is done, I think it would be great if, once element(s) are selected, the relevant part of the tree is automatically "scrolled to" within the inspector window and that section is opened (uncollapsed).

I'm not sure what the "relevant part" of the tree would be for a given item. The Inspector dialog only has relevant parts for the element selected. In Isaac's sample he posted there were 3 sub-menus collapsed that the user could chose to expand. Perhaps if you default to the position ("element" in Isaac's sample) being expanded that would make sense because it is common to every element I can think of.

I was assuming a tree view widget would show all properties, available to selected element(s) or not.

Because the note for example has so many different options, I would argue that the element should automatically be expanded and the rest be available for expansion if needed by the user. If you expand all properties then some of the options would probably scroll off the bottom and force the user to change his view in some way. The "elements" submenu would probably scroll off of the top and (in my experience) is the most likely to be altered.

And except that by default we dock it to the right.

Another one: there's a pretty big difference for line properties between right-click → Line Properties and the Line (and Volta/Hairpin/Ottava/Text Line) Inspector, some properties are only available in one, some in the other, some in both.

Why are there so many posts about this :(
Please see https://musescore.org/en/node/296410, the discussion is now taking place there.

I think we've already come to a stage where movable dialogues have all been moved, except for major overhauls not actually talked about in this issue. Now we will just have to wait for Tantacrul's inspector redesign for more.

Automatically closed -- issue fixed for 2 weeks with no activity.