-
-
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
Migrate ControllerEngine to QJSEngine + improve error handling #1795
Migrate ControllerEngine to QJSEngine + improve error handling #1795
Conversation
81e6002
to
b51f457
Compare
56f88d1
to
6a8f52b
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.
Thanks for getting started on this!
I made a pull request to update scripts now that ControllerEngine::getThisObjectInFunctionCall is not available with QJSEngine. |
I have been thinking about whether it's a good idea to introduce C++ exceptions here, which AFAIK are not used anywhere else in Mixxx. I know many developers advise against ever using exceptions, or at least avoid them in C++. I don't have enough experience with them to have much of an opinion about that (although Rust's Result enum seems much better because always it forces the caller to deal with potential problems), but I don't think C++ exceptions are necessary or helpful in this code. I understand it intuitively corresponds to JS Error objects, but I think it compounds the problem of this code being overcomplicated with inconsistent behavior. The overcomplicated code was there before you started working on it, but I think it would be wise to clean it up while working on this code. There are many different places in ControllerEngine where JS code is evaluated. Each of these have subtly different behavior when an error occurs. Sometimes an annoying dialog is shown, sometimes it just logs a warning, and it's not clear if the possibility of JS errors is properly handled every time they may happen. I think it would be better to wrap all calls to QJSEngine::evaluate in a single function that handles the possibility of errors. Throwing an exception from that function requires a bunch of redundant try-catch code every time the function is called, which kinda defeats the point of having a reusable function. |
Don't bind "this" in beginTimer and makeConnection callbacks Adapt ControllerEngine::checkException for QJSEngine Rename checkException to handleEvaluationException
Since QJSEngine takes ownership of exposed QObjects it tried to delete controller and controllerengine when QJSEngine was destroyed (i.e script reload and mixxx shutdown). See https://bugreports.qt.io/browse/QTBUG-41171 This also has the benefit that we have a tighter control on what's exposed. Since Signals and slots, properties and children of object are available as properties of the created QJSValue, lots of undesired things were leaked into the JS engine.
This helps inspecting the test results in eclipse test inspector.
Remove bytearrayclass since now QJSEngine has built in support for QByteArray, which gets converted to a JS ArrayBuffer.
6a8f52b
to
b3380ba
Compare
Please add new commits instead of rebasing. I cannot easily tell what you changed in the code since the last time I looked at it and now my PR does not cleanly merge. If we decide to clean up the history later, we can do that at the end before merging. |
The old hacks for preserving the "this" object for engine.makeConnection, engine.connectControl, and engine.beginTimer do not work with QJSEngine, but QJSEngine brings support for ES5, which supports Function.prototype.bind. https://bugs.launchpad.net/mixxx/+bug/1733666
The old hacks for preserving the "this" object for engine.makeConnection, engine.connectControl, and engine.beginTimer do not work with QJSEngine, but QJSEngine brings support for ES5, which supports Function.prototype.bind. https://bugs.launchpad.net/mixxx/+bug/1733666
The old hacks for preserving the "this" object for engine.makeConnection, engine.connectControl, and engine.beginTimer do not work with QJSEngine, but QJSEngine brings support for ES5, which supports Function.prototype.bind. https://bugs.launchpad.net/mixxx/+bug/1733666
fixing |
# Conflicts: # appveyor.yml # build/depends.py # res/controllers/midi-components-0.0.js # src/controllers/controller.h # src/controllers/controllerengine.h # src/controllers/engine/colorjsproxy.cpp # src/controllers/engine/controllerengine.cpp # src/controllers/hid/hidcontroller.cpp # src/preferences/dialog/dlgpreferences.cpp # src/preferences/dialog/dlgpreferences.h # src/skin/skincontext.cpp # src/skin/skincontext.h # src/test/controller_preset_validation_test.cpp # src/test/controllerengine_test.cpp
# Conflicts: # src/preferences/dialog/dlgpreferencesdlg.ui
Hmm there's still a merge conflict with src/preferences/dialog/dlgpreferencesdlg.ui |
I need to fix tests and do some manual testing |
I already started resolving merge conflicts that emerged due to my recent controller related changes, but then I noticed that this doesn't build as-is. A fix can be found here: ferranpujolcamins#15 Also, the
|
controllers/bulk: Fix BulkController constructor
Ping. This still fails both with cmake and scons. |
Conflicts resolved here: ferranpujolcamins#16 |
ColorMapper and ColorMapperJSProxy are fixed here: ferranpujolcamins#17 ControllerPresetValidationTest.MidiPresetsValid is failing in a strange way. It is saying there is an exception in Components when loading mappings that don't use Components??
|
Actually the tests do work. I got confused because CMake does not install the mixxx-test binary; it has to be run from the CMake build directory. I took the next step and implemented an API for scripts to work without XML mappings: #2682 |
@ferranpujolcamins merge conflicts are already solved in #2682. I think we can close this PR without merging now. |
This was introduced in PR mixxxdj#1795 when the migration to QJSEngine was planned for a release when the latest Ubuntu version shipped Qt 5.9, which did not support ES7. The purpose was to show users an error when they loaded a script using ES7 if they were using a Qt version before 5.12. Since Mixxx 2.3 took so long, the QJSEngine migration will be released when the latest Ubuntu LTS (20.04) ships Qt 5.12, so we do not need to introduce this "controller engine version" concept anymore. Mixxx will still build and run with Qt < 5.12 at the small cost of keeping only one #if in ControllerEngine::throwJSError, but mappings using ES7, which now includes any mapping using the Components library, will not work.
This was introduced in PR mixxxdj#1795 when the migration to QJSEngine was planned for a release when the latest Ubuntu version shipped Qt 5.9, which did not support ES7. The purpose was to show users an error when they loaded a script using ES7 if they were using a Qt version before 5.12. Since Mixxx 2.3 took so long, the QJSEngine migration will be released when the latest Ubuntu LTS (20.04) ships Qt 5.12, so we do not need to introduce this "controller engine version" concept anymore. Mixxx will still build and run with Qt < 5.12 at the small cost of keeping only one #if in ControllerEngine::throwJSError, but mappings using ES7, which now includes any mapping using the Components library, will not work.
To do
Add unit tests?Test availability of exposed methods to JSInstall svg extension manuallyCompletely remove QtScript classesMake error messages translatable