[MS4] pluginType "dock" not working anymore
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
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.
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 thepanels
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.
In reply to The dock plugin type is… by dmitrio95
Thank you both for your answers! Thanks dmitrio for sharing your insights and code. I like the API compatibility switch. I'll probably do it similar and just provide a window in MS4 for now. That at least should be stable.
In reply to The dock plugin type is… by dmitrio95
Hi, I noticed the commented out lines for
openLog
andlog2
to log from the plugin. Do they actually work? I've copied how you used it, but I don't see any log files being generated.In reply to Hi, I noticed the commented… by matt28
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 (thefilePath
property is described here). Also there is acloseLog()
line, it may also be better to enable it to ensure the log file is properly closed and written to the filesystem.In reply to Yes, they worked for me… by dmitrio95
Here's what I did:
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…
In reply to Here's what I did: onRun: … by matt28
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 usingopenLog(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.
In reply to I have just checked this,… by dmitrio95
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?
In reply to Thank you! Using the… by matt28
Do you mean that shortcuts defined by such plugin do not work? I only know that plugins are able to define shortcuts using the corresponding Shortcut type, but I have never used this myself so I do not know which limitations this approach has.
In reply to Do you mean that shortcuts… by dmitrio95
.
In reply to Hi Dimitri, here is the… by gustebus10
.