[MS4] pluginType "dock" not working anymore

• Dec 18, 2022 - 19:11

In MuseScore 4, my plugin with

    pluginType: "dock"
    dockArea:   "left"

doesn't show up when I start it. No error messages are displayed in the console.

With pluginType: "dialog" the plugin works. There is no issue on GitHub about this.

Does anyone know if dock support is planned or how to work around that? I could use dialog but that means I have to care about window size and position and it likely gets in the user's way at some point.

Comments

• Dec 19, 2022 - 12:33

It'll probably be reinstated at some point; as per the announcement no real work effort has been spent on the plugin API yet.
Dockables probably broke because of their whole new UI rewrite which uses different panels.

Reply

• Dec 19, 2022 - 20:32

The dock plugin type is indeed unsupported in MuseScore 4, but if it is really necessary (or just fun to do it), it can be worked around. I made a small test plugin to debug this (attached here: DockPlugin.qml), and also included this workaround to the Fretboard plugin, so you can also see it there.

The idea is, since the UI is written in QML and even appears to share the same QML engine with plugins, plugins can make use of large parts of the API available to the UI components. This API is apparently not meant to be public and stable, but it can be used to get something working.

With this engine we have the ui global property which points to the engine itself which has few important properties, like the pointer to the root item of the UI. By searching through the root item's children we can find the notation page which is the page when we want our dock plugin to appear. We can wrap then our widget into an item suitable for adding to the dock system and just append it to the panels list.

The curious part is getting our new panel to show. With MuseScore native panels this happens via the "dock-toggle" command which shows a dock panel given by its objectName. This command cannot be invoked directly from a plugin. However a plugin can invoke a command to show one of the existing dock panels, like palettes or piano keyboard. Therefore we can abuse this system by pretending our panel to be, say, a piano keyboard, telling MuseScore to show the piano keyboard and then renaming all the objects back. The plugin's dock panel would appear in the same place as the piano keyboard (or whichever panel your panel has pretended to be) — it may even appear to be floating if the user has previously undocked the original panel. Therefore with this method you do not have full control over the place where the plugin's panel would appear, but it does work and does add a plugin-originated panel to the MuseScore's dock widgets system. The new panel can then be docked, moved and closed just like any other dock panel.

Overall, it looks like the fact that the UI is mostly written in QML will give a lot of interesting and unexpected possibilities to plugins, despite they will require some effort to discover and will be not as stable as the public plugin API can afford.

Reply

• Feb 23, 2023 - 12:42

Yes, they worked for me. Maybe you can try to specify a full path to the log file, something like openLog(filePath + "/" + "log-file-name.txt") should make it appear in the same directory as the plugin file itself (the filePath property is described here). Also there is a closeLog() line, it may also be better to enable it to ensure the log file is properly closed and written to the filesystem.

Reply

• Feb 23, 2023 - 17:04

Here's what I did:

  onRun: {
    console.log('Started Xen Tuner');
    // When you want to find which import has a syntax error, uncomment this line
    // console.log(JSON.stringify(Fns));
    showDock();

    var isMS4 = mscoreMajorVersion >= 4;
    Fns.init(Accidental, NoteType, SymId, Element,
      fileIO, Qt.resolvedUrl("../"), curScore, isMS4);
    openLog(filePath + '/xen tuner 0.4.log');
    log2('test', 'test xen tuner');
    log2('present working dir', Qt.resolvedUrl("../"));
    closeLog();
    console.log('present working dir: ' + Qt.resolvedUrl("../"));
  }

Though, the log file doesn't appear to be created.

Which version of MS are you currently using? I'm using yesterday's 4.1.0 dev build: https://github.com/musescore/MuseScore/commit/ad2a416fb064e037da542b9db…

Reply

• Feb 23, 2023 - 23:44

I have just checked this, the filePath property doesn't seem to be working in MuseScore 4. Therefore it indeed fails to create a log file. However Qt.resolvedUrl(".") seems to give the plugin's directory as well, so I am able to create a log file in the plugin's directory by using
openLog(Qt.resolvedUrl(".").replace("file://", "") + "/dock-plugin.log");

Logging also works if I specify just the file name instead of a full path. Then the log file is created at the current working directory of the program, but it may appear to be non-writable (or just difficult to locate) if running the program from the system's GUI.

I am using MuseScore 4.0.1 on Linux, but I don't think this behavior has changed in the recent versions of MuseScore.

Reply

• Feb 24, 2023 - 20:52

Thank you! Using the absolute path and removing the "file:///" prefix (or "file://" for mac/linux) does the trick.

Though, I am now faced with another issue where defined Qt application shortcuts don't seem to work on the 'dock hack'. Do you have any tips for configuring shortcuts?

Reply

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