Public bug reported: 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. ** Affects: oxide Importance: Medium Assignee: Chris Coulson (chrisccoulson) Status: Triaged ** Changed in: oxide Importance: Undecided => Medium ** Changed in: oxide Status: New => Triaged ** Changed in: oxide Assignee: (unassigned) => Chris Coulson (chrisccoulson) -- You received this bug notification because you are a member of Ubuntu WebApps bug tracking, which is subscribed to Oxide. https://bugs.launchpad.net/bugs/1453294 Title: Expose some classes as value types to QML Status in Oxide Webview: Triaged 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. - 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. To manage notifications about this bug go to: https://bugs.launchpad.net/oxide/+bug/1453294/+subscriptions -- Mailing list: https://launchpad.net/~ubuntu-webapps-bugs Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs More help : https://help.launchpad.net/ListHelp
