- Timeframe: 5.14, 5.15
- notmart to help with info
- Done (D14536)
But there's a needed API break in Q_INVOKABLE QList<EffectWindow*> EffectWindow::mainWindows();
QList<QObject*> is understood by QML, QList<QObjectDerived*> is not.
Changing the invokable signature is a C++ API break, moving the invokable to a new place is a JS api break.
QQmlListProperty<QObjectDervied*> is Qt's solution, we we're not going to be able to change Qt.
It's not in a place we can wrap in the scripting, it's in an object we expose.
There are 4 solutions:
- We break API on the C++ (we don't claim to be stable, and we're breaking ABI every release anyway)
- We break API of the JS (it's an obscure function, we can see all users on kde-look and it's not used, ideally it should be a property anyway)
- Something absolutely horrific tricking Qt moc so we can have a different C++ signature with the invokable name
- Something absolutely horrific shadowing both Effects global and EffectWindow in the script engine so we can mod them.
All options suck somewhat.
There's also an issue QJSEngine not having a warning signal like QQmlEngine this we should be able to fix in Qt.
Are you sure QML can't handle QList<QObjectDerived*>. kwineffects.h only forward declares EffectWindow so Qt/QML might not be able to tell it is QObject derived, and EffectWindow, EffectWindow* and QList<EffectWindow*> are also not registered as a metatypes (though QVector<EffectWindow*> is)
QQmlListProperty is to support the returned value being treated as a proper JS Array, which we can't do with a C++ container.
Though if the JS expect the property or function to return something usable as a JS Array, then yes, that will not work and can not work.
Anyway if you are breaking C++ ABI anyway routinely, then that sounds like the way forward.