Options for debugging QML plugins?
Hi,
When attempting to convert to QML some of my plugins, I am finding quite complex to debug anything non-trivial, as the new plugin framework as no debugger.
QML documentation in Qt help is not reassuring: as ways to help debugging QML code, it mentions debugging the whole application (which I can do, but most users are not ready or willing to do) or some thing called "slow motion".
Now:
1) I suspect "slow motion" has no way to look at variables or objects and
2) debugging the whole MuseScore in order to trace plugin execution is not very useful as the Qt debugger gets often confused when executing QML code (it loses track of variables) at least under Windows 7.
Had anyone any success in debugging QML plugins?
Is there any plan / idea to improve the situation? If plugins are hard / impossible to debug, the probability of having in the future a fair number of reliable plugins might drop substantially.
Thanks,
M.
Comments
For now you can use the plugin editor and console.log() calls. Not very elegent and quite cumbersome to use, but better than nothing.
Which plugins are you trying to convert, any of your published ones?
In reply to For now you can use the by Jojo-Schmitz
Yes, you are right, I forgot to mention this possibility; it is useful to catch syntax errors and little more, I'm afraid.
With console.log() I spent an afternoon to catch an error (better, a change in member names) which whould have taken five minutes to notice with a debugger, even minimal.
Which plugins: none of the published ones, but a few which I use for my Renaissance editions: too rough and of too limited interest to 'publish' them.
In reply to Yes, you are right, I forgot by Miwarre
I have several plugins on GitHub , in various states of QML readiness, anywhere between fully functional (ColorVoices, blacknotes), working with restrictions (e.g. notenames), untested, not working all and not yet ported ;-). Maybe those can serve as examples?
In reply to I have several plugins on by Jojo-Schmitz
They will be useful indeed! Thank you for this ground-opening work.
However, this will ease the development of new plugins only for the tasks which are common to several plugins; new code will need debugging...
Thanks,
M.
It has been 3.5 years since the publication of this message. Are there any new ideas/techniques for debugging Qml plugins with QtCreator's debugger?
In reply to It has been 3.5 years since by straannick
Not that I know. Anybody else has news about this?
In reply to Not that I know. Anybody else by Miwarre
Nope. Nothing changed.
It's possible to debug QML from Qt creator, so it should be possible to debug MuseScore and MuseScore QML plugins too but we probably miss some infrastructure to make it work.
In reply to Not that I know. Anybody else by Miwarre
Thank you, Miwarre!
But you wrote:
"2) debugging the whole MuseScore in order to trace plugin execution is not very useful as the Qt debugger gets often confused when executing QML code..."
I can't understand how you had managed to trace plugin execution, can you explane, please, and what to do after
p->runPlugin();
In reply to Thank you, Miwarre! But you by straannick
The few times a console.log within the plugin and the Plugin Creator's debug output couldn't help me out I did it like this:
1. Launch MuseScore from Qt Creator by starting a debug session
2. Set breakpoints in the calls we want to debug.
For Example, for this bug my plugin used
curScore.firstSegment()According to the built-in documentation, this is a method of the Score object.
I looked up 'firstSegment' in libmscore\score.h and found it as a Q_INVOKABLE (which means this is the function called from QML)
Put my breakpoint at the first line of Score::firstSegment from libmscore\score.cpp
3. Running the plugin will now trigger the breakpoints on the corresponding C++-code, allowing you to inspect local variables and functionality
Note that this is not at all the same from being able to put breakpoints within your plugin and stepping through those statements...
In reply to Thank you, Miwarre! But you by straannick
I used the same method described by jeetee. As you can imagine, it is a pain in the neck and it does not really amount to debugging your plug-in, but rather MuseScore itself while executing your plug-in.
In practice, no 'real' debugging so far.