-
-
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 legacy controller system to QJSEngine #2682
Conversation
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.
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
Thanks for debugging that. I committed the fix 6e96bdb. Ready for merge? |
The Travis failure is from an unrelated test failure, probably spurious. |
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.
The diff is too large to review this properly, but I didn't encounter issues during manual testing.
@mixxxdj/developers Does anyone else want to take a look or can I hit merge?
@ferranpujolcamins and I have both gone over this code thoroughly. This has been in progress since August 2018. I really don't want to keep holding it back. We've already had hassles fixing merge conflicts over that time. Let's get this in already. |
Alright, merged. |
Woo, our first major step towards 2.4! |
nice! any news about the svg script? |
I don't know. I haven't looked into that at all. But we do still need to remove the deprecated Qt Script from the skin system before it is removed from Qt, which I suspect will happen with Qt6. |
from a quick look, it looks like it's not used at all since the svg extension is disabled. |
I don't know, but if you want to experiment with that, go for it! |
I think QML has native JS support, right? Maybe we should switch over our custom skinning system to QML before adding more features. |
Yes, but that's a much bigger project than what @ronso0 is proposing. |
Yeah, looking forward to a first QML POC! But looking at the 2.4 ToDo/plans I doubt this will happen before 2.5!? I'd start experimenting, but I don't want to add tons of new stuff. |
I suspect we should wait until Qt6 before fully embracing QML. |
This builds on @ferranpujolcamins's work to migrate to QJSEngine for ES7 support (#1795). This PR ports the Components library to use ES6 classes.
Note: Mixco mappings for Korg NanoKontrol2 and MAudio Xponent are removed, unmaintainable