Programming Questions

• Sep 12, 2017 - 01:38

So I've got a few general questions about contributing to Musescore.

I've got 3 more-or-less overlapping PR out there... the first a trivial change to PluginCreator, the second a series of more complex changes to PluginCreator (and PluginManager) to 3.0dev, and a third where I ported those changes to 2.2 because 3.0 is not really stable yet and I put those changes in because I wanted to use them.
And now I've been fiddling more, but the outstanding PRs are in limbo (among other things Travis-CI appears to have thrown a cog)
1) Should I try and keep PRs separated were possible, or should I just keep tweaking the existing ones?
2) Is it worth doing PRs for 2.2? (If the added features are easily backward compatible)
3) The chosen style guide is doing my head in... particularly the requirement for spaces between operators. I've never used that coding style, and half the time I literally can't see it when I've forgotten. Has anyone got a handy Regex to search for non-spaced operators in QtCreator? (not fix, just find)

Any help appreciated.

Comments

• Sep 12, 2017 - 04:29

Ad1) Depends on whether they are independent of one another. One Pr should better not dependend another.
Ad 2) PRs for 2.2 are rarely needed, git cherrypick mostly does a good job to pull master commits over to 2.2. I think your PR for master should apply cleanly to 2.2, except for one line, and about that laconic already said that he can deal with it.
Ad 3) There is a settings file in the developers' handbook to get QtCreator to do most of the formatting right.

Reply

• Sep 15, 2017 - 01:01

So, still looking at Plugins... in 3.0 most of the plugin elements are commented out, and the Element type has been wrappered with ElementW.
Can anyone enlighten me on what the thinking is here?
I'd like to start uncommenting the various elements so I can start seeing how Plugins behave, but I don't want to break things for other people.

Reply

• Sep 15, 2017 - 13:28

The plan is to make the script interface lighter. First step was to remove the QObject base class and the use of Qt properties. Instead use a wrapper for Element and use the MuseScore properties. You can access a property with the ElementW::get(const QString& propertyName) function (see testfile "walk.qml").

Reply

• Sep 23, 2017 - 09:31

So, here's the deal.
I've been working on getting the Plugins operational in 3.0
As such I have done the following work:
* Converted random.qml to MuseScore 3.0, and made sure it worked.
* Fixed newElement to return an ElementW.
* Implemented a wrapper for TimeSig to support additional methods required to set a TimeSig from qml.
* Added a static method to Element to support creating customized wrappers as required. (buildWrapper)
* Added a "set" method to allow setting properties, to go with the "get" method already implemented.
* Added support for to get a list of supported properties: a readProperties and a writeProperties, each return a list of readable and writeable properties.
All this is in branch plugins_30 at https://github.com/rjmatthews62/MuseScore

So, question, do I keep going? Is this going to interfere with what anyone else is doing?
My immediate plan is to rewrite all the current "share/plugins" to work with MuseScore 3.0, as well as adding internal support as required.

Reply

• Sep 25, 2017 - 19:31

I can't speak for Werner regarding the stability of the framework or anything about future direction that you should have in mind. But speaking for myself and many others, I thank you for taking this on! Anything that makes the plugin ecosystem more viable to programmers and/or users is extremely welcome.

Reply

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