Skip to content
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

Merged
merged 10 commits into from
Sep 30, 2021

Conversation

Be-ing
Copy link
Contributor

@Be-ing Be-ing commented Sep 27, 2021

Somehow this is hanging in the ControllerManager destructor. It seems the requestShutdown signal does not trigger slotShutdown so m_pThread->wait() blocks indefinitely.

@Be-ing Be-ing marked this pull request as draft September 27, 2021 06:47
src/qmlapplication.h Outdated Show resolved Hide resolved
src/qmlapplication.h Outdated Show resolved Hide resolved
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

Any ideas why ~ControllerManager is hanging?

@uklotzde
Copy link
Contributor

Any ideas why ~ControllerManager is hanging?

I didn't have time to test it yet. Will do later.

@Be-ing Be-ing force-pushed the qmlapplicationengine branch 3 times, most recently from 7372c3c to 7be95d5 Compare September 27, 2021 19:43
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

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++.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

Well this is really ugly. Initialization of the effects system depends on the existence of a DlgPreferences instance.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

Even uglier: the hang in ~ControllerManager goes away when a DlgPreferences instance is created.

Copy link
Contributor

@uklotzde uklotzde left a 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.

src/qml/qmlapplication.h Outdated Show resolved Hide resolved
src/qml/qmlapplication.h Outdated Show resolved Hide resolved
src/qml/qmlapplication.h Outdated Show resolved Hide resolved
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

More ugliness: I cannot include include preferences/dialog/dlgpreferences.h in src/qml/qmlapplication.h because compiling main.cpp fails with:

In file included from ../src/qml/qmlapplication.h:4,
                 from ../src/main.cpp:14:
../src/preferences/dialog/dlgpreferences.h:13:10: fatal error: preferences/dialog/ui_dlgpreferencesdlg.h: No such file or directory
   13 | #include "preferences/dialog/ui_dlgpreferencesdlg.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

I tried adding

add_executable(mixxx WIN32 src/main.cpp src/qml/qmlapplication.cpp)
set_target_properties(mixxx PROPERTIES AUTOUIC ON AUTOMOC ON)

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?

@github-actions github-actions bot added the ui label Sep 27, 2021
@Be-ing Be-ing force-pushed the qmlapplicationengine branch 2 times, most recently from 0a8c937 to 2dfe7fc Compare September 28, 2021 02:39
@Be-ing Be-ing requested a review from Holzhaus September 28, 2021 04:12
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

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.

0  DlgPreferences::~DlgPreferences() (this=0x9c1d060, __in_chrg=<optimized out>) at ../src/preferences/dialog/dlgpreferences.cpp:297
#1  0x000000000059394a in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (this=0x9c1d050)
    at /usr/include/c++/11/bits/shared_ptr_base.h:168
#2  std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (this=0x9c1d050) at /usr/include/c++/11/bits/shared_ptr_base.h:161
#3  std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (this=0x7fffffffdc48, __in_chrg=<optimized out>)
    at /usr/include/c++/11/bits/shared_ptr_base.h:705
#4  std::__shared_ptr<DlgPreferences, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (this=0x7fffffffdc40, __in_chrg=<optimized out>)
    at /usr/include/c++/11/bits/shared_ptr_base.h:1154
#5  std::shared_ptr<DlgPreferences>::~shared_ptr() (this=0x7fffffffdc40, __in_chrg=<optimized out>) at /usr/include/c++/11/bits/shared_ptr.h:122
#6  mixxx::qml::QmlApplication::~QmlApplication() (this=0x7fffffffdc00, __in_chrg=<optimized out>) at ../src/qml/qmlapplication.h:19
#7  0x00000000005740c9 in (anonymous namespace)::runMixxx (args=<optimized out>, pApp=0x7fffffffdbc0) at ../src/main.cpp:41
#8  main(int, char**) (argc=<optimized out>, argv=0x7fffffffddd8) at ../src/main.cpp:189

@Be-ing Be-ing force-pushed the qmlapplicationengine branch from 2dfe7fc to 4900acf Compare September 28, 2021 04:19
src/qml/qmlapplication.cpp Outdated Show resolved Hide resolved
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

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.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

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:

QWidget: Cannot create a QWidget without QApplication

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.

@Holzhaus
Copy link
Member

Holzhaus commented Sep 28, 2021

Just setting this to false doesn't work?
https://doc.qt.io/qt-5/qguiapplication.html#quitOnLastWindowClosed-prop

@Holzhaus Holzhaus closed this Sep 28, 2021
@Holzhaus Holzhaus reopened this Sep 28, 2021
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

Ha! That looks like a simpler solution, thanks.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

Adding

    app->setQuitOnLastWindowClosed(false);
    app->setQuitLockEnabled(false);

to the QmlApplication constructor does not solve the problem.

@Be-ing Be-ing force-pushed the qmlapplicationengine branch from 4900acf to 030237e Compare September 28, 2021 16:24
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 28, 2021

I found a one line fix:

m_pDlgPreferences->setAttribute(Qt::WA_QuitOnClose, false);

Now to deal with the hang in ~ControllerManager...

@Be-ing Be-ing force-pushed the qmlapplicationengine branch from 0f791df to 78c5913 Compare September 28, 2021 22:04
src/errordialoghandler.cpp Show resolved Hide resolved
src/preferences/dialog/dlgprefinterface.cpp Show resolved Hide resolved
res/qml/main.qml Outdated Show resolved Hide resolved
@Be-ing Be-ing force-pushed the qmlapplicationengine branch 2 times, most recently from 413b745 to dced202 Compare September 29, 2021 16:10
@Be-ing Be-ing requested a review from uklotzde September 29, 2021 16:10
Copy link
Member

@Swiftb0y Swiftb0y left a 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
@Be-ing Be-ing force-pushed the qmlapplicationengine branch from dced202 to 74f8693 Compare September 29, 2021 23:50
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 29, 2021

Merge?

@Be-ing Be-ing changed the title decouple QML from legacy skin system decouple QML from legacy skin system + add preferences button Sep 30, 2021
@Be-ing Be-ing mentioned this pull request Sep 30, 2021
@Swiftb0y Swiftb0y merged commit 431d107 into mixxxdj:main Sep 30, 2021
@Be-ing Be-ing deleted the qmlapplicationengine branch September 30, 2021 12:55
@Holzhaus
Copy link
Member

This PR leads to 2 major regressions:

  1. Closing any popup closes Mixxx. E.g. if a track fails to load, a popup will open. If you close it, Mixxx shuts down.
  2. It's not possible to use the developer tools anymore, which makes QML skin development extremely tedious.

@Be-ing
Copy link
Contributor Author

Be-ing commented Dec 13, 2021

Closing any popup closes Mixxx. E.g. if a track fails to load, a popup will open. If you close it, Mixxx shuts down.

Qt::WA_QuitOnClose needs to be set to false for every QWidget window: https://github.com/mixxxdj/mixxx/pull/4327/files#diff-2768d0d13eda8f9b18b5ce2c75faed57cb48c7f8463612e674455561533234f7R63

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants