← Back to team overview

ubuntu-webapps-bugs team mailing list archive

[Bug 1453294] Re: Expose some classes as value types to QML

 

** Changed in: oxide
       Status: Triaged => Fix Released

** Changed in: oxide
    Milestone: None => branch-1.9

-- 
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:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1453294/+subscriptions


References