Plugin API feature wanted: OnSelectionChange for Dock plugins

• Sep 13, 2019 - 12:08

The final link in facilitating supplying "missing" inspector functionality would be to allow dock-type plugins an optional method OnSelectionChange, which would be called by C++ whenever the user clicks on any element, selecting it, or on nothing, deselecting any extant selection. With this feature, a dock-type plugin could supplement the inspector by always showing you now-unshown properties of notes (or other elements), editable, of course, with an Apply button, allowing (in effect) user extensions to the inspector, without having to type a shortcut to bring up a plugin for each note. When editing articulations, for instance, this would reduce the number of gestures (click, shortcut, type number, apply) by 25%, and if you click on a note you decide you don't want to change, by 66% (now click, shortcut, ESC). Native support in the inspector would have almost no advantage over this (other than disappearing or coming back on F8).


Comments

I have added an experimental feature to plugins API which allows tracking selection changes (and any potential score changes in general), see this commit (the documentation on that will be uploaded a bit later). This possibility implies several possible issues so API is not stable yet but it would be great if you could try it out and give your feedback on this. I believe this could indeed be a potentially very useful feature for plugins framework.

Bug:

Reloading the plugin in the plugin creator (by Run or anything else) doesn't clear the cached onScoreStateChanged; MuseScore seems to have cached a pointer to it that doesn't go away, so it's impossible to change it once it has seen it (without restarting MuseScore).

In reply to by [DELETED] 1831606

> There seem to be undesirable side-effects of perusing ranges with cursors (i.e., ostensibly read-only operations affecting the UI state of the score).

Do you mean that onScoreStateChanged gets called even for operations which do not change score? If so then this is almost intentional: this handler gets called every time MuseScore itself updates its widgets' state. To distinguish cases where something particular in a score has changed (and not viewport, for example) the state variable is available there, but it currently lacks some useful information (like a range of possibly changed elements or something like that).

In reply to by dmitrio95

No. What seems to happen is that when my range-scanning code, using cursors, runs during onScoreStateChanged (without my last fix to it), I can no longer insert notes in the score: it says "No current position to insert notes", even when i click on notes. When I added "cursor.rewind(1)" to the end of the scanning code, the problem seems to go away. If this isn't enough, I can describe it further or provide a test case.

When there is a selected note, and I click on empty space (not in a staff), I get onScoreStateChanged called, but not the state.selectionChanged flag (the Inspector and status line correctly erase their holdings, though). If I click on the blank space again, my onScoreStateChange is called, but this time with state.selectionChanged set. I have programmed around this with the somewhat bogus behavior of clearing my display (if up) if a state change not selectionChanged occurs; I'd rather do it correctly.

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