Possible Improvements to Plugin Management`

• Sep 4, 2017 - 14:36

Ok, I've made a toe-in-the-water contribution (adding a separate "Save As" to the pluginCreator)

I've got a few ideas in that area which I think help, and also a few questions.
Ideas first:
* editor should auto-indent.
* Help should be a little more verbose and offer a bit more guidance.
* "New" should include a default description line
* dialogs should not immediately be hidden while using 'run' (main screen comes up over the top)

* Should be smart enough to realise changes have been made to the plugins, and/or there should be a refresh button. Currently a modified plugin doesn't pick up the new code without restarting musescore.
* Plugin Console window on main screen would make debugging easier.

All these things are things I think are simple, will significantly ease plugin development, and something I can contribute. So, what's the next step? Create an Issue?
How do we discuss whether this is a good idea or if someone else is working on it?

Also, the latest MuseScore is version 3.0 for the plugin import. Do we want to consider backward compatibility for previous versions?
I notice that quite a lot of the old MuseScore 1.0 QMLregistrations are commented out... is that something else I should be looking at?

Any guidance appreciated.


All of these are great. Go for it. You can create an issue per feature if you like or bundle them all in an issue but in any case refer to the issue number in your commit message (fix #XXXXX)

If your changes are simple enough that they would not break, I can merge them manually in 2.2 branch which might be ready before 3.0.

I don't believe it will be possible to have backward compatibility. So I would go for MuseScore 3.0 and shape the API for 3.0 the way we want.

Currently a modified plugin doesn't pick up the new code without restarting musescore

Agreed, one of the changes I'm working on (after getting a better understanding of internal Qt differences between loading from a file vs loading from code) is to create a (private) PluginLoader class for a PluginManager (non-visual) in order to unify the loading/behavior of plugins loaded by MS as part of the startup routine and plugins loaded as part of the editing process in the Plugin Creator.

Once that effort is done, it should be easier/trivial to force reloading of a plugin.

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