ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

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