Plugins don't work in the recent Qt5 nighlies

• Jul 12, 2013 - 11:48
S4 - Minor

2c8f6fd, Windows 7

manually loading and trying to run e.g. the colornotes plugin gives:
creating component failed
line 14: module "QtQuick" is not installed


This time the following files are missing:

Actually, plugins seem to work even if plugins.qmltype is missing, but this file is referenced inside qmldir, so probably also:
should be added.
These files are located in

You mean colornotes should work with thos additional files ABL mentioned in place, right? Because without it certainly does not, not on my PC anyway

I just tried my custom build, and was going to report that Colornotes worked because it did. After that, as a test, I renamed my Qt directory (even though I have no paths to Qt in my PATH variable) and then the Colornotes plugin would not load at all, even though it's set to load. I never did see any error messages about QtQuick.

I do see the message now. I also get a crash when trying to execute Colornotes through the Plugin Manager with the proper Qt path. When run as just a plugin from the menu things work fine.

When I copied the QtQuick.2 folder into MS and renamed the Qt folder, the plugin showed and ran from the menu, but crashed when running it through the plugin manager. Somewhere MS is remembering the Qt path which is _not_ a good thing. The Qt path is definitely not in my PATH variable.

Yesterday evening I had some free time to check: the crash happening when running from the PluginCreator is due to line 314 of mscore/pluginCreator.cpp:
because dock is not created since the colornote plugin returns false on the check (item->pluginType() == "dock") (thus dock is 0).
one of commits 4fbe30a6 and 8c2425e4 changed something and now the colornotes plugin freezes when launched (at least in my personal build: it was working in 2c8f6fdd).
For what concerns the hardcoded path, I had raised and closed an issue (, since it is solved in Qt: in Windows Qt libraries first try to search the needed dlls in the local folder, and if they fail they search in the hardcoded qt path. Provided that all the required files are in place in MuseScore bin folder [even the one for which Qt does not display a warning :-) ], everything should work Ok.

My proposal solution on Windows would be to override completely the QMLEngine import path and set it to MuseScoreInstallDir/qml and then make sure that the Qml modules are installed there. A similar approach will be needed on Mac. For linux, it should be smoothier since Qt is installed by the packaging system.

The Problem is also not really solved for Windows: colornotes gets MuseScore into a loop and it freezes.
So do we need a new (and critical) issue for this?

Thanks Nicolas for the fix.
However, probably the Qt debug dlls present in the qml folder can be skipped, saving roughly 24.4 MB of disk space.
I mean the following files:

(they have a trailing "d" in the filename with respect to the regular "release" dlls).

Woule adding a line to mscore/CMakeLists.txt at around line 412 do?

REGEX ".*d\.dll" EXCLUDE

Or is this something for the release Version later, leaving the debug libs in the nightlies for, well, debug purposes?

At least in my personal build, also the debug compilation ("mingw32-make -f Makefile.mingw debug") does not link against the Qt debug dlls, but against the "release" Qt dlls. Maybe additional flags have to be added during compilation for the debug ones to be linked.
As things are at the moment, Qt debug dlls seem to be useless in the win32install folder.

[ For what concerns the CMake question, unfortunately I know nothing of CMake syntax: I will let people with more knowledge answer instead :-) ]

I don't have a clean mac VM to check, but yes, I pushed a fix. Waiting for confirmation from someone without a trace of Qt on his Mac.