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

migrate legacy controller system to QJSEngine #2682

Merged
merged 169 commits into from
Jun 14, 2020

Conversation

Be-ing
Copy link
Contributor

@Be-ing Be-ing commented Apr 19, 2020

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

ferranpujolcamins and others added 30 commits November 24, 2018 13:28
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
@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 13, 2020

Thanks for debugging that. I committed the fix 6e96bdb. Ready for merge?

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

The Travis failure is from an unrelated test failure, probably spurious.

Copy link
Member

@Holzhaus Holzhaus left a 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?

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

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

@Holzhaus Holzhaus merged commit 441e49c into mixxxdj:master Jun 14, 2020
@Holzhaus
Copy link
Member

Alright, merged.

@Be-ing Be-ing deleted the migrate-to-QJSEngine branch June 14, 2020 12:12
@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

Woo, our first major step towards 2.4!

@ronso0
Copy link
Member

ronso0 commented Jun 14, 2020

nice!

any news about the svg script?
back then, the reason to disable it was the implementation of QScriptDebugger. Is it now possible to re-enable it? Would still be handy for setting up a large number button icon templates with Variables, especially during the skin design process.

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

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.

@ronso0
Copy link
Member

ronso0 commented Jun 14, 2020

deprecated Qt Script from the skin system

from a quick look, it looks like it's not used at all since the svg extension is disabled.
So we need to migrate that to QJsEngine, as well? Would that suit to have rudimentary skin scripting? Like 'outsourcing' nested 'visible' connections for showing a certain Spinny for example?

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

I don't know, but if you want to experiment with that, go for it!

@Holzhaus
Copy link
Member

I think QML has native JS support, right? Maybe we should switch over our custom skinning system to QML before adding more features.

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 14, 2020

Yes, but that's a much bigger project than what @ronso0 is proposing.

@ronso0
Copy link
Member

ronso0 commented Jun 14, 2020

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.
The only goal isto find a simple way to include a skin script like latenight.script that does some basic toggling and therefore allows simplifying skin templates, because toggling widgets in/visibilbe causes delays and glitches IME.

@Be-ing
Copy link
Contributor Author

Be-ing commented Jun 15, 2020

I suspect we should wait until Qt6 before fully embracing QML.

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

Successfully merging this pull request may close these issues.

7 participants