https://bugs.kde.org/show_bug.cgi?id=423643
--- Comment #10 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
(In reply to Fabian Vogt from comment #8)
> The doc says:
> > Warning: This function is useful only for registering an alias (typedef)
> > for every other use case Q_DECLARE_METATYPE and qMetaTypeId() should be
> > used instead.
Interesting hint, not seen before, thanks. Though after a while I think this
also should hint that for non-aliases one should still want to use "template
<typename T> int qRegisterMetaType()" to achieve registration as needed beyond
usage with QVariant, like for queued signal and slot connections etc.
Having now played & dug some more, actually with the current usages the
qmlRegisterInterface seems not needed for those 3 classes, as they are not used
with any QML properties, but only as objects in JavaScript code, if at all.
At least by what
grep Q_PROPERTY . -R | grep "Service\|DataSource"
done over all the Plasma repos told me.
And by my experiments the JS engine seems happy enough with the "normal"
registrations to the meta-object system.
So by example of the bug as reported here, clicking the vlc systray icon to
toggle window display:
```
Q_INVOKABLE Plasma::ServiceJob *startOperationCall(const QVariantMap
&description, QObject *parent = nullptr);
// no qmlRegisterInterface
qRegisterMetaType<Plasma::ServiceJob *>();
```
-> works
```
Q_INVOKABLE ServiceJob *startOperationCall(const QVariantMap &description,
QObject *parent = nullptr);
// no qmlRegisterInterface
qRegisterMetaType<Plasma::ServiceJob *>("ServiceJob*");
```
-> works
Now, the org.kde.plasma.core module is surely loaded everywhere in Plasma. And
there is a small chance something 3rd-party relies on the current registrations
as interface with QML without knowing. And having broken things just before I
feel I want to propose now to just mark all this as KF6 TODO only in another MR
:)
--
You are receiving this mail because:
You are watching all bug changes.
