Expose some classes as value types to QML

Bug #1453294 reported by Chris Coulson on 2015-05-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Medium
Chris Coulson

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

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

Changed in oxide:
importance: Undecided → Medium
status: New → Triaged
assignee: nobody → Chris Coulson (chrisccoulson)
description: updated
Changed in oxide:
status: Triaged → Fix Released
milestone: none → branch-1.9
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers