MuseScore community plugin developer's library anyone?
I'm back to scrambling around in the pitch black night that is plugin development in MuseScore. One persistent annoyance is the re-inventing of wheels all the time. I'm specifically thinking of the code that gets a cursor, figures out if there is a current selection or not then iterates over the cursor in different ways depending on that condition. Everyone seems to have their own version or even versions of that, but I'm sure there are other examples.
I'm suggesting we plugin developers might collaborate on a shared library of common utilities, rather than have to search one another's code. I'm aware that the plugin creator has issues with Qml scripts including other files (the plugins themselves work fine) but assuming that could be fixed if it hasn't been already, then a high-level library would have the additional benefit of protecting developers and their plugins from changes in the Qml/MuseScore substrate, making future porting easier.
I'd envision we would just need to sub-class the MuseScore class in Qml, and add to that, but I haven't tried it yet.
Comments
I strongly recommend my red note and articulation plugins (see "articulation" in the plugins page) as clear examples of both these things. There are now two kinds of selections, ranges and collections of objects, and they (variably) handle both.
The Qt 5.9/5.12 issue is going to require painstaking documentation. I volunteer to contribute.
Looks like one has started here...
Contains nothing that will change the reinvent the wheel issue...
In reply to Looks like one has started… by ecstrema
I was more thinking of documentation; the issue of how to modularize plugin code such that subroutine libraries become useful is unclear, esp considering version conflict issues (cf python "virtual env" construct).
Copy and paste works fine to avoid reinventing the wheel.
In reply to Copy and paste works fine to… by mike320
to copy paste, examples would be needed in the docs...
By standardizing recurring functions like cursor handling and selection checking, you can not only save time but also ensure consistency across plugins. I agree that a high-level library could help mitigate the risk of changes in the QML/MuseScore core affecting individual plugins. Collaborating on such a resource would make it easier to maintain and port plugins in the future. If you're able to get around the issues with QML scripts including other files, it could certainly improve the developer experience.