QtScript is not well maintained and deprecated in favor of QJSEngine.
This is still WIP because callDBus isn't yet ported.
QtScript is not well maintained and deprecated in favor of QJSEngine.
This is still WIP because callDBus isn't yet ported.
Lint OK |
No Unit Test Coverage |
Buildable 11107 | |
Build 11125: arc lint + arc unit |
Current status:
callDBus is still not ported. I have the following list of potential ways how to do it:
In all three cases I'm worried about reply arguments, e.g. if there is any QDBusVariant reply argument, we have to unwrap it.
Implement callDBus.
I went with the second option. Overall, the solution doesn't
look nice, but it works.
In long term, I think it would be nice to introduce a module
for such things, e.g.
const dbus = require('dbus'); dbus.makeMethodCall({ service: 'org.kde.KWin', path: '/KWin', interface: 'org.kde.KWin', method: 'supportInformation', onFinished: (text) => console.log(text), onError: (err) => console.log(err) });
In all three cases I'm worried about reply arguments, e.g. if there is any QDBusVariant reply argument, we have to unwrap it.
That's true of the current state. Not just for QDBusVariant but for any complex type we demarshall that doesn't have a script-friendly metaobject attached.
In addition to 4 required arguments, specify N optional QVariant arguments;
That's what we do for i18n in kdeclarative. It's not super clever but pragmatically easy to read.
In long term, I think it would be nice to introduce a module
If we're thinking long term with API breaks it would be better to have something generic for all Plasma - as well as removing duplication between this and the QQmlEngine scripting.
Argh, it's not possible anymore to do
client.geometry = { x: 0, y: 0, width: 42, height: 73 };
Potential solution would be to introduce some sort of Qt.rect, but that would break existing scripts. :(
Given that we have to break compatibility, KWin 6 is probably a good time to port scripting.