Plugins for 3.0
There are a number of structural changes happening for plugins in 3.0
As Element is now not descended from QObject any more, anything exported to the qml engine (ie, plugins) needs to be wrapped in something that is.
Werner had already started work on this, but it was in a fairly incomplete state.
I've added a bunch of stuff to make plugins functional, and converted some scripts to work in the new plugin framework.
I've got a PR pending, but if you are curious latest source is here:
https://github.com/rjmatthews62/MuseScore (branch plugins_30)
Things that need to be done:
* Someone has to start writing a guide on the changes (I'm willing to get it started, but need editing access to our wiki(?)
* I have so far only exported a handful of objects, and converted a few scripts to work. (See: walk.qml, colornotes.qml, proplist.qml and random.qml). I intend to do more progressively.
* The help files are falling behind, in part due to a new method of accessing Musescore properties.
So, since this is a work in progress, I could do with some feedback/discussion on the best way forward.
For example:
cursor.element and cursor.segment are now cursor.element() and cursor.segment() (ie, functions not properties)
Most musescore specific properties can be accessed by get and set, ie, note.get("color") and note.set("color","red")
Element types are now in the Ms namespace, so it is now Ms.NOTE, not Element.NOTE
You can find out the properties an element supports with readProperties and writeProperties, which return an array of property names supported by that element.
readProperties returns readable properties, writeProperties returns writeable properties. These are usually the same, but not always.
I'm not entirely sure about the thinking behind get and set, and am wondering whether it is a good plan to also export them as actual qml properties... I am open to suggestions.
Comments
Work progresses.
https://github.com/musescore/MuseScore/pull/3303
Would still like to get some feedback...
AFAICT, all default plugins have been converted and will run in 3.0
Latest work in https://github.com/musescore/MuseScore/pull/3303
I've also added some documentation:
https://musescore.org/en/handbook/plugins-20
and
https://musescore.org/en/handbook/plugins-30
Stylistically, does anyone have a strong preference for functions vs read only properties?
In reply to Stylistically, does anyone… by Robbie Matthews
I get the choice for function with stringargs from a main codebase maintenance pov; but I would prefer properties as it comes more natural to most qml/javascript programmers.
In reply to I get the choice for… by jeetee
I'm tending towards properties as well. There's not a lot of difference coding wise internally.
I do think we should pick a standard approach and stick with it, though.
In reply to I'm tending towards… by Robbie Matthews
functions (or rather methods) for code that actually does something (different from just getting or setting a variable), properties for the rest
In reply to functions (or rather methods… by Jojo-Schmitz
This to me is actually an argument for functions. Even if the current implementation is able to implement something as a simple property, encapsulating as a function seems more future-proof. That's more a general observation than anything specific to the 3.0 plugin architecture of which I know little, but something to consider.
In reply to This to me is actually an… by Marc Sabatella
In this case, get and set are quite useful, and act as a form of future proofing.
At the moment I'm also exporting them as properties some of the time if it makes things more convenient, but as stated this is a work in progress, it's a big job (and one I still don't know is going to be taken up.)
I could get behind the "if it does something, make it a function, if it just returns a value, make it a property" principle.
I don't suppose there is a list anywhere of what all the properties do? I've made a start on them here: https://musescore.org/en/handbook/plugins-30
... but it would help if there was something I could refer to.
In reply to functions (or rather methods… by Jojo-Schmitz
So, measure.next() or measure.next ?
(Currently there are examples of both styles in the code).
In reply to So, measure.next() or… by Robbie Matthews
IMHO measure.next()
Hmm, maybe not.
while (measure.next) { // if there's a next neasure
measure.next() // go there
...
}
In reply to IMHO measure.next() by Jojo-Schmitz
I don't think qml allows for that distinction... (ie, I don't think I can have .next and .next() in the same object..)