Myths of the 21st century: plugin concurrency?
OS: macOS 10.14, Arch.: x86_64, MuseScore version (64-bit): 3.3.0.23833, revision: d3bff12
With my dock plugin active, I used a shortcut to activate another, non-dock, non-dialog plugin. The dock plugin was therewith closed and vanished from the screen. Easy enough to get back, but this is not right; this works against the very purpose of docking plugins.
I thought concurrency of plugins was a major issue and design-constraint on object use; it is apparently not possible!
Comments
I suspect that this may happen because that another plugin calls
Qt.quit()to signal about finishing its execution. The interesting part is that this triggersQQmlEngine::quit()signal which makes it impossible to distinguish which plugin has called it, at least if we are not going to make a separate engine for each plugin. So just all plugins get eventually closed. I wasn't aware of that when I initially worked on restoring plugins functionality for MuseScore 3 so just made it the same as it was in MuseScore 2, and later it was somewhat late to change this. On the other side, it may happen that we will actually need to have a separate engine per plugin if we are going to create a mechanism to control access to certain resources for plugins (like network, local filesystem).So the problem is indeed interesting, but for now a workaround should be just to remove
Qt.quit()from any other plugins you run until the issue gets resolved.In reply to I suspect that this may… by dmitrio95
Interesting. What would be the effect of removing Qt.Quit() in the dialog and no-UI cases? Presumably dialogs shown will not go away.
In reply to Interesting. What would be… by [DELETED] 1831606
Yeah, this fixes it for the no-UI plugin (rednote), but I worry about the ones with dialogs --how can they take down their dialogs (and I guess they'll have to restore their initial state if the engine doesn't go away)??
In reply to Yeah, this fixes it for the… by [DELETED] 1831606
This is basically a coding guideline change for plugins, that Qt.quit() should rarely, if ever, be called, for it is no plugin's charter to close down other (dock) plugins. As to what to do with Dialog plugins, research and maybe core change (short of "separate engines") is needed.
In reply to This is basically a coding… by [DELETED] 1831606
A separate engine for each plugin would make the ultimate goal of unique wrappers that much more difficult. What is needed is a new "ShutdownThisPlugin" API call that does just that and only that.
There is some light at the end of this tunnel; with my dock plugin up, I invoked the triller plugin (a dialog plugin), and dismissed it with the OS red "close" button on the titlebar; whatever it did, it (a) closed and (b) did not dismiss the docked plugin. Plugins should be doing whatever-that-does instead of QtQuit(). What does that do and is it QML accessible?
In reply to There is some light at the… by [DELETED] 1831606
I tried close(), parent.close(), and parent.parent.close() in a button handler without success; all were undefined. The QML documentation says that close() exists on QML dialogs, but lists QtQuickDialogs 1.3 as its source (which is not available to our plugins). Can this be fixed easily (i.e., 1.3 made available)? Can you try that to see if it works?
In reply to I tried close(), parent… by [DELETED] 1831606
Is that maybe part of a later Qt version, newer than your 5.9?
In reply to Is that maybe part of a… by Jojo-Schmitz
This says 5.3, if I'm not mistaken: https://doc.qt.io/qt-5/qml-qtquick-dialogs-dialog.html .
In reply to This says 5.3, if I'm not… by [DELETED] 1831606
Setting parent.visible, parent.parent.visible to false only blacks out the dialog, doesn't hide the frame.
In reply to Setting parent.visible,… by [DELETED] 1831606
"close()" in the button handler (correctly) hides the button, but parent.close() (Grid) and parent.parent.close() (api/dialog) fail.
In reply to This says 5.3, if I'm not… by [DELETED] 1831606
Ah, I see. Then those should be available, unless it's been removed in later releases?
import QtQuick.Dialogs 1.3works in 3.2.3 on Windows 7, it fails for you?In reply to Ah, I see. Then those should… by Jojo-Schmitz
import QtQuick.Dialogs 1.3 fails for me. Let me try again to make sure I didn't mess up somehow. Where can I look in the tree to see exactly what I've got?
In reply to I don't know what version of… by [DELETED] 1831606
Running…
Creating component failed
line 20: module "QtQuick.Dialogs" version 1.3 is not installed
If you tell me where MS is hiding it, maybe I can steal the one in MS2 you see...
In reply to I don't know what version of… by [DELETED] 1831606
No idea, I just tried various numbers and 1.3 is the highest I can import without getting an error message.
But on Windows and as such using Qt 5.12.2 vor MuseScore 3.2.3 and Qt 5.12.5 for MuseScore 3.3RC
In reply to No idea, I just tried… by Jojo-Schmitz
That's grim. So maybe on the Mac dock and dialog plugins can't run together, and the plugin code must therefore do the same on Windows as well.
In reply to That's grim. So maybe on… by [DELETED] 1831606
If this is truly a 5.12 vs 5.9 problem, we should implement an API write-around usable in 5.9 which would allow dialog-type plugins to close themselves harmlessly on either platform.
In reply to If this is truly a 5.12 vs 5… by [DELETED] 1831606
"dialog" type plugins are not implemented with
QtQuick.Dialogsso you cannotclose()that dialog like the dialogs from that package. It looks like currently the only way for dialog plugins to quit is indeed to callQt.quit().In reply to "dialog" type plugins are… by dmitrio95
Well, that helps a great deal (to know that). What is invoked by the OS title-bar Close icon on the window? It works just fine --- Can we expose a bridge to that in QML?