About exporting bindings to JavaScript



  • We ran into a tricky issue while exporting a QObject to webkit [removed]
    We have an object A, derivating from QObject (obviously), with pure virtual slot f1
    Object B, derivating from object A, overloads slot f1 with actual implementation

    @
    class A:public QObject {
    Q_OBJECT
    public slots:
    virtual void f1(QString,QString)=0;
    };
    class B:public Q{
    Q_OBJECT
    public slots:
    virtual void f1(QString,QString);
    }
    @

    Object B is exposed to a webview, as b (note : we tried to qobject cast to a as well...)

    • trying to call b.f1('a','b') in Javascript leads to
      @
      Error evaluating command: Exception: ambiguous call of overloaded function f1(); candidates were
      f1(QString,QString)
      f1(QString,QString)
      @
      After deep analysis, looks like both objects are moc'd and exportation layer isn't able to deal with that.
      Solution, in object B, define f1 as a standard function and not a slot, that way, it won't be moc'd but use native CPP derivation.
      The way presented does work with standard signal and slots however.

    • when some exposed native objects are connected (signal/slots) to JS objects, realoding the qwebview prevents some objects to be freed. In case you have increasing memory consmption, try to explicitely disconnect your JS slots.

    • exposing complex objects is somehow tricky, to propose infomation, we used QList/QMap/QVariant : this allows complex structure to be correctly exposed

    • using default values in exposed slots does not work well (we had a bunch of issues)

    • all signals and slots are exposed, even from derivated objects : if you have internal stuff you dn't want exposed, use shell objects. Especially, we didn't see a way to prevent some QObjects slots to be exposed (like deleteLater, which is not virtual)

    After deep experiments, we finally went to KISS: keep exposed objects as simple as presentation objects as possible, export data as simple as possible. and don't overdo the JS part. Exposing too much only links to more complex bugs.

    I hope these few notes will prevent other teams to be stuck like we were :-)



  • I strongly recomend to read one "white paper":http://developer.qt.nokia.com/wiki/Hybrid_application_with_Qt before doing any thing with QT and web. Please also have good reading of Qt "webkit bridge":http://doc.qt.nokia.com/4.7-snapshot/qtwebkit-bridge.html documentation.



  • Development started 1.5yrs ago and is based on Qt 4.6, some of this might be outdated or now documented. Thanks for pointing at these references, hope my few lines can still help a few lost developpers ;-)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.