API improvments

• Apr 25, 2022 - 17:17

Hi,

I listed improvement needs in the API that emerged from discussions I've been part of in the last weeks and months.

Need/Issue Discussion Issue ref
Clef element details are not available Bossa Nova setting/plugin?
Sibling elements in other parts/excerpts are not exposed Get cursor to score from parts
Fret diagrams dots and bars are not available Retrieving Fret diagrams details
Getting the "parent" score for curScore when curScore is an excerpt of this "parent" score How to get a "full score" object when curScore is one of the score excerpts ?
Dots not exposed for rests Plugin: Accessing rest dots
Key signature details not available How to add a KeySignature ? #100501
Changing bar to a StartRepeat bar doesn't work correclty Changing a barline type via code

I just cloned the GitHub repo. I'm going to (try and) build it.

Can some of the MS experts point which of the items I listed might an easy one to start with ?
And in which branch to work ? I see no "4.xx" branch. Anyone is working in the "main" branch ?
To avoid making pull request that won't be accepted, is there a process, for validation or review of the User Stories, ... ?

In short, is the whole process about providing code's update described somewhere ?

Thanks


Comments

On the note of plugin request; one thing I'd personally like to see return is the strong typing of elements and their properties as it was in MS2 compared to the shitload of defined but not-relevant properties on the generic "Element" level.

I get that having the plugin API tied directly into the libmscore code (as it was in MS2) has it's downsides; and I get that throwing it all in an abstraction bunch for MS3 was "faster" than creating decent wrappers for all elements. But it makes discovering properties from the QML/JS side a lot harder. Things like inspection loops using hasOwnProperty all broke and finding a relevant property became a guessing game (even if there is an automatic documented API with the long list of "perhaps relevant" properties).

In reply to by parkingb

Quick question: when developing that plugin (or any other one for that matter), do you have a faster way of getting MS to see any change in the .qml/.js files than clicking the reload button in the Plugin Creator?

What is your typical development cycle like i.e. how do you change code - get MS to see the new code - test?

Thank you!

In reply to by gregsadetsky

The Development cycle is not ideal.
I work most of time in Notepad++, for both the .qml files and the .js files.
When I've modified a .qml file I reload it in the Plugin Creator.
When I've modified a .js file , there is no other choice than going in MuseScore and reloading the plugins (Plugin manager menu, and then Reload the plugin). Because those external files are loaded only once. The same applies to other types of external files, such as images files.

In reply to by parkingb

Got it, thank you for your answer!

I haven't done any tests in MS to confirm whether this would work or not, but I'd be curious if a .js file could dynamically include another .js file (through an eval i.e. a poor man's import) and thus always see the latest version of the (downstream) .js file.

Having an external way of triggering the "Plugin reload" command would also be useful, but as that would require custom development, I imagine that it's more out of reach.

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