Scripting is two parts:

• ScriptedEffects
• Scripting

ScriptedEffect status:

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