-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decouple QML from legacy skin system + add preferences button #4327
Conversation
Any ideas why ~ControllerManager is hanging? |
I didn't have time to test it yet. Will do later. |
7372c3c
to
7be95d5
Compare
Effects including EQs are not working with QML. I tested merging #2618 but that does not fix it. There must be some implicit dependency of the effects system on the setup of the legacy GUI. Moving controller knobs for EQs changes the QML, so it seems the QML is okay and the problem is in C++. |
Well this is really ugly. Initialization of the effects system depends on the existence of a DlgPreferences instance. |
Even uglier: the hang in ~ControllerManager goes away when a DlgPreferences instance is created. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropping the "skin" prefix from namespaces and file paths is a good idea. We have skins and we have qml, mutually exclusive. This avoids to distinguish between legacy skins and QML skins.
More ugliness: I cannot include include preferences/dialog/dlgpreferences.h in src/qml/qmlapplication.h because compiling main.cpp fails with:
I tried adding
to CMakeLists.txt and removing src/qml/qmlapplication.cpp from the sources list for the mixxx-lib target. Unfortunately the build still fails. CMake is generating ui_dlgpreferencesdlg.h but it is located in build/mixxx-lib_autogen/include/preferences/dialog/ui_dlgpreferencesdlg.h which is not in the list of include paths for the mixxx executable target. Any suggestions how to resolve this? |
0a8c937
to
2dfe7fc
Compare
I made a QML button to show the preferences but I am puzzled how closing the preferences window triggers the QmlApplication destructor. I set a breakpoint in ~DlgPreferences which shows that DlgPreferences is properly getting deleted by QmlApplication... but why is QmlApplication getting destroyed in the first place when DlgPreferences is closed?? It does not matter whether DlgPreferences is closed by the Okay, Apply, or Cancel button or the window manager close button. I commented out adding all the pages in the DlgPreferences constructor but I still reproduced the issue. I also tried creating a QQuickView instead of a QQmlApplicationEngine but the issue still occurred.
|
2dfe7fc
to
4900acf
Compare
Well this is interesting. I replaced the DlgPreferences instance with a simple QDialogButtonBox and reproduced the issue of QmlApplication shutting down when the widget is destroyed. |
I figured out the problem. QApplication's event loop shuts down the QApplication when the last QWidget window is closed. I confirmed this by showing a dummy QDialogButtonBox then opening the preferences from QML. In that case, I could close the preferences without shutting down the application but the application shut down after closing both the preferences and the dummy QDialogButtonBox. I attempted changing MixxxApplication to subclass QGuiApplication instead of QApplication, but then it is not possible to use any QWidgets at all; at runtime console output showed:
So I think we need to filter out the erroneous QEvent::Close event in MixxxApplication when the QQmlApplicationEngine is still showing to avoid needing to rewrite the whole preferences in QML immediately. |
Just setting this to false doesn't work? |
Ha! That looks like a simpler solution, thanks. |
Adding
to the QmlApplication constructor does not solve the problem. |
4900acf
to
030237e
Compare
I found a one line fix:
Now to deal with the hang in ~ControllerManager... |
0f791df
to
78c5913
Compare
413b745
to
dced202
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I'd like to have a second opinion before merging if possible.
to prevent closing QWidget error dialogs from shutting down Mixxx when using the QQmlApplication GUI
That was required for hacking QML into the legacy skin system but it created a regression with the cursor getting stuck on the splitter dragging handle: https://bugs.launchpad.net/mixxx/+bug/1943860
dced202
to
74f8693
Compare
Merge? |
This PR leads to 2 major regressions:
|
Qt::WA_QuitOnClose needs to be set to false for every QWidget window: https://github.com/mixxxdj/mixxx/pull/4327/files#diff-2768d0d13eda8f9b18b5ce2c75faed57cb48c7f8463612e674455561533234f7R63 |
Somehow this is hanging in the ControllerManager destructor. It seems the
requestShutdown
signal does not triggerslotShutdown
som_pThread->wait()
blocks indefinitely.