This time the following files are missing: MuseScoreNightly\bin\QtQuick.2\qmldir
MuseScoreNightly\bin\QtQuick.2\qtquick2plugin.dll
Actually, plugins seem to work even if plugins.qmltype is missing, but this file is referenced inside qmldir, so probably also: MuseScoreNightly\bin\QtQuick.2\plugins.qmltypes
should be added.
These files are located in C:\Qt\5.1.0\mingw48_32\qml\QtQuick.2
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: dock->widget()->setAttribute(Qt::WA_DeleteOnClose);
because dock is not created since the colornote plugin returns false on the check (item->pluginType() == "dock") (thus dock is 0).
BUT
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 (http://musescore.org/en/node/20998), 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: qml\QtQuick\Layouts\qquicklayoutsplugind.dll
qml\QtQuick\Controls\Private\qtquickcontrolsprivateplugind.dll
qml\QtQuick\Controls\qtquickcontrolsplugind.dll
qml\QtQuick\XmlListModel\qmlxmllistmodelplugind.dll
qml\QtQuick\Dialogs\dialogplugind.dll
qml\QtQuick\PrivateWidgets\widgetsplugind.dll
qml\QtQuick\Window.2\windowplugind.dll
qml\QtQuick\Particles.2\particlesplugind.dll
qml\QtQuick\LocalStorage\qmllocalstorageplugind.dll
qml\QtQml\Models.2\modelsplugind.dll
qml\QtQuick.2\qtquick2plugind.dll
qml\Qt\labs\folderlistmodel\qmlfolderlistmodelplugind.dll
(they have a trailing "d" in the filename with respect to the regular "release" dlls).
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 :-) ]
Comments
This time the following files are missing:
MuseScoreNightly\bin\QtQuick.2\qmldir
MuseScoreNightly\bin\QtQuick.2\qtquick2plugin.dll
Actually, plugins seem to work even if
plugins.qmltype
is missing, but this file is referenced inside qmldir, so probably also:MuseScoreNightly\bin\QtQuick.2\plugins.qmltypes
should be added.
These files are located in
C:\Qt\5.1.0\mingw48_32\qml\QtQuick.2
colornotes should work, some other plugins currently do not work b.c. of problems with the "Ms" C++ namespace.
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.
You'd see that message if you load and (try to) run if from the Plugin Creator
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.
More info about import path for QML here http://qt-project.org/doc/qt-5.0/qtqml/qtqml-syntax-imports.html#qml-im…
I will check this problem further tomorrow.
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
:dock->widget()->setAttribute(Qt::WA_DeleteOnClose);
because
dock
is not created since the colornote plugin returns false on the check(item->pluginType() == "dock")
(thusdock
is 0).BUT
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 (http://musescore.org/en/node/20998), 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.
Fixed in 2e86dd005e
the null dock problem is solved, but not the missung DLLs nor the path issue
sorry, I missed the other commit...
I let this one active since it still needs to be solved on Mac.
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?
What we need is a fix ... but yes, please open another bug report.
ABL experienced that freeze too, and I think it has to do with the change in 4fbe30a6
I've just created #21819: colornote plugin freezes MuseScore
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:
qml\QtQuick\Layouts\qquicklayoutsplugind.dll
qml\QtQuick\Controls\Private\qtquickcontrolsprivateplugind.dll
qml\QtQuick\Controls\qtquickcontrolsplugind.dll
qml\QtQuick\XmlListModel\qmlxmllistmodelplugind.dll
qml\QtQuick\Dialogs\dialogplugind.dll
qml\QtQuick\PrivateWidgets\widgetsplugind.dll
qml\QtQuick\Window.2\windowplugind.dll
qml\QtQuick\Particles.2\particlesplugind.dll
qml\QtQuick\LocalStorage\qmllocalstorageplugind.dll
qml\QtQml\Models.2\modelsplugind.dll
qml\QtQuick.2\qtquick2plugind.dll
qml\Qt\labs\folderlistmodel\qmlfolderlistmodelplugind.dll
(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?
Like:
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 :-) ]
Removing them makes the archive more than 4MB smaller.
Debug libs are removed. Thanks for the regex Jojo, it was almost correct.
Ah, yeah, double backslash, should have though about that...
I guess this is now fixed for Mac too with 72ae5171?
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.
Ok. This is fixed!
Automatically closed -- issue fixed for 2 weeks with no activity.