| 2015-07-02 14:47:16 |
Chris Coulson |
description |
We have several classes that are only QObects because they need to be exposed to QML (eg, OxideQLoadEvent, OxideQDownloadRequest). QObjects aren't copyable, which causes some problems:
- When used in signals, they have to be passed as pointers. This prevents them from being used in queued slots, unless they are dispatched in a QSharedPointer that can be shared between slots. QSharedPointer can't be used with QML though.
- In a slot, it's not possible to store the pointer and act on it asynchronously. If an application implements an onLoadEvent handler, it should be possible to do "obj.prop = event" and be able to access obj.prop after the slot finishes. The same is true for onDownloadRequest - the embedder might want to act asynchronously on the request. We currently can't do that though, because the instance is deleted once the signal has ran and so the embedder has to implement extra code to do a deep copy of all of the object's properties.
Qtdeclarative has a private API for exposing custom value types (copyable types that aren't QObject) - see QQmlValueType. IIUC, in a future qtdeclarative release, there's a public mechanism for doing this (see https://www.qt.gitorious.org/qt/qtdeclarative/commit/2b5fb185627f8adfb6c5b3d62990a58429bf4ea7).
Given that there's going to be a public way to do this, I think it would be worthwhile using the private API for current qtdeclarative releases (which isn't going to change anymore) before we adopt a newer release. Some candidates for converting to value types are LoadEvent, DownloadRequest and SslCertificate.
One thing I've wanted to do for a while is to have a stable C++ API, but I've been reluctant to commit to this because I've never really been happy with implementing everything as QObjects. This would be a stepping stone to having a stable C++ API. |
We have several classes that are only QObects because they need to be exposed to QML (eg, OxideQLoadEvent, OxideQDownloadRequest). QObjects aren't copyable, which causes some problems:
- When used in signals, they have to be passed as pointers. This prevents them from being used in queued slots, unless they are dispatched in a QSharedPointer that can be shared between slots. QSharedPointer can't be used with QML though.
- When used in signals, the pointer passed to QML becomes invalid as soon as the stack unwinds. This means that if you implement WebView.downloadRequested in QML and store the request in a property somewhere to act on it asynchronously, the request object become invalid. The only way around this would be to add extra code to deep copy it.
- OxideQSecurityStatus::certificate() returns a pointer to OxideQSslCertificate, and the ownership remains with Oxide. If the certificate for the current page changes, the old pointer becomes invalid (and any handles in QML referring to the old certificate become invalid too). It would make much more sense for OxideQSecurityStatus::certificate() to return a value that can be copied around instead.
Qtdeclarative has a private API for exposing custom value types (copyable types that aren't QObject) - see QQmlValueType. IIUC, in a future qtdeclarative release, there's a public mechanism for doing this (see https://www.qt.gitorious.org/qt/qtdeclarative/commit/2b5fb185627f8adfb6c5b3d62990a58429bf4ea7).
Given that there's going to be a public way to do this, I think it would be worthwhile using the private API for current qtdeclarative releases (which isn't going to change anymore) before we adopt a newer release. Some candidates for converting to value types are LoadEvent, DownloadRequest and SslCertificate.
One thing I've wanted to do for a while is to have a stable C++ API, but I've been reluctant to commit to this because I've never really been happy with implementing everything as QObjects. This would be a stepping stone to having a stable C++ API. |
|
