Right-click menu on palette items seems dead.

• Dec 5, 2018 - 12:15
Reported version
3.0
Priority
P2 - Medium
Type
Graphical (UI)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project

(Mac, Mojave, 3.0.0.19499) Right-click on any element of a palette, key signature, time signature, ornament, etc. pops up an expectable little menu (usually "Clear" "Properties" "More"). None of the menu items ever seems active.


Comments

Status active needs info

Is it a custom workspace and the palette enabled for editing? If not, by design. Works for me as expected if the workspace is custom

I see. An app should not pop up menus all of whose items are foreclosed. It should say "Can't edit builtin (non-custom) workspace".

Status needs info active
Workaround No Yes
Priority P0 - Critical

Indeed. There is a workaround: type something in search field and remove right after that.

@JoshuaBonn1 looks like something for you :)

In reply to by Anatoly-os

I don't understand why a "workaround" is needed, or what you are suggesting. I am complaining that a menu that does nothing is offered. If it offends me, I shouldn't call it up, but I don't want others to be confused.

Priority P0 - Critical P2 - Medium

FWIW, it's the same as 2.3.2 in that we display a greyed out menu. But it's a bug that typing into the search then deleting it changes things to allow non-editable cells to be edited. Not sure it's really critical, though. Even if you delete something from, say, the Advanced palette, the change isn't really saved. So I don't see how it's critical?

@Marc indeed, I tested this with custom workspace. And there was a bug: I could not delete a cell until I did the described manipulation. If it becomes possible to delete cells in predefined workspaces, it is a bug, indeed.

I understand BSG's pain, so I would prevent showing the context menu if nothing can be done there. Not critical since 2.3.2 behaves the same.

Status active PR created

So the bug of being able to edit palettes in Basic and Advanced stem from this line of code: https://github.com/musescore/MuseScore/blob/master/mscore/palettebox.cp…
When filtering starts, it disables all edits. However, once filtering stops, it enables edits for all palettes without concern of their original status. Instead of ever changing the readOnly option for filtering, we might as well use the preexisting filterActive boolean to decided if edits are allowed.

As for disabling the context menu all together, a simple check of all menu items being enabled fixes that.

https://github.com/musescore/MuseScore/pull/4321