Move "Fretboard Diagram Properties" into Inspector

Double click on any element in the score enters "edit mode" and edit mode let you move the element with the arrows on your keyboard. So I would not change this behavior for consistency. Properties of an element are always accessed via a right click. We could maybe think about another shortcut, like Alt + click

See #118086: Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3.

Well, this feature ("Move "Fretboard Diagram Properties" into Inspector") has already been implemented since many months! And so, for the 2.0.3 :)
Ditto for the Bend properties (see image below)
So, we can close this specific feature request, right?

Not exactly what I mean. It should be simply:

Requested again at https://musescore.org/en/node/156176.

Definitely disagree. Again remember that some users prefer to work with the closed Inspector. And in this case, the context menus are just perfect...

Regarding context menus, part of the broader request at #118086: Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3 is to make "Inspector" a context menu option.

Context menus are "just perfect" if you don't mind the additional indirection for occasional edits. But surely adding this extra behavior to the inspector would not require eliminating the context menus? Both usage modes are helpful. For occasional adjustment to chord diagrams, the context menus are fine. But they are inconvenient when creating a richly-detailed score with unique (i.e. custom, non-library) diagrams on every beat; this is common in guitar education. In that case, the proposed inspector model would be a big time-saver. What is the objection to adding power to the inspector? When displayed, it generally has a lot of unused space, so why not make that available for controlling important properties and behavior? I think this applies to many other UI elements, such as controlling entries on the Lines palette.

Additionally, putting it in the Inspector would allow multiple selected fretboard diagrams to be adjusted at once.

Oh, I hadn't thought of that, yes that is highly desirable.

And in general, orthogonal feature design says that pretty much *anything* should be modifiable using the inspector. There's no reason to exclude anything from inspector control.

We have various context menu shortcuts, keyboard shortcuts, and similar mechanisms to speed interaction, but the core interface should (I think) let us a) single-click on anything and see/manage it in the inspector, b) single-click on anything and be able to adjust the physical placement, if relevant, and c) double-click on anything and get to a useful direct-modification interface.

I'm not sure what you mean by "orthogonal," but I think that would be a consistent user experience. It would be a more major overhaul, however. As things currently stand, you can a) single-click on most things and see/manage it at least a little bit in the Inspector, b) right-click on some things (that overlap with a) and choose "___ Properties..." to manage it in a popup dialog (accessing different options than a), c) single-click on text objects and adjust the physical placement, and d) double-click on anything *except text objects* and adjust the physical placement.

Sorry, I'm slightly generalizing this term, a concept we relied on heavily when designing languages, systems, user interfaces, etc. The idea is that you work with a relatively small number of primitive elements that can be combined in consistent ways, and minimize exceptions and surprises.

My favorite user interfaces (and languages) have elements with very predictable interactions, in support of the Law of Least Astonishment. See e.g. http://en.wikipedia.org/wiki/Orthogonality_(programming)

Regarding my suggestion that *everything* be modifiable with the inspector, I was thinking about what I thought *was* a long-term goal, and of course achieving that *would* involve a significant overhaul...or more likely, a gradual evolution moving toward that goal. (I was picturing a "master inspector," analogous to the "master palette," that owns and reveals the entire datastructure.)

I have no problem with the current inspector-plus-properties-popup approach, as long as the things we need the most often are accessible via the inspector...but that's where we run into divergent use cases with different users needing different things. The fretboard diagram properties are a case in point. When chord symbols are thought of as a small static library of a few dozen chords, analogous to other symbols, then it makes sense for the popup to do most of the UI work. But in situations when most chord diagrams must be custom-created in context, quite common in some applications, then the popup adds a lot of extra mouse clicks.

Regarding your comment about the 'Properties' dialog being used for *different* options from those shown in the inspector, I really disagree with that approach. I would always prefer for the most detailed control interface to have *every* element, and for the less-detailed interface to be a subset of (or a specialized editor for) the data. Dividing the data between two interfaces seems to invite confusion. (By analogy, I'd hate for some of the standard palette symbols to be missing from the master palette.)

Sorry for diverting the discussion into user interface philosophy.

8ca085ca partially addresses this by copying the "Strings" and "Frets" parameters into the Inspector, while still leaving them duplicated in the Properties dialog.

Fixed in 0c4e596e5.

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