Plugins for 3.0

• Sep 27, 2017 - 06:55

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: (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.


In reply to 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 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:
... but it would help if there was something I could refer to.

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