Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Unsolved QWebEngineView v QWebView

    General and Desktop
    1
    1
    766
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      coquetangler last edited by coquetangler

      With the recent removal of QWebView from Qt 5.6 and 5.7 I've been investigating the possibility of creating a proxy wrapper class called QWebView that makes calls into QWebEngineView.

      The async nature of the calls into QWebEngineView can be handled by looping reading events and dispatching them until the async callback is made.

      However, calling methods on objects in Qt from within the blink/V8 engine breaks too many applications. I understand the rationale behind using async calls rather than sync calls but nevertheless this makes it much more difficult to port applications that previously used WebKit...

      I have built V8 and have it integrated in our product already since Qt5. V8 has a reasonably decent API that provides the ability to extend it with C functions (property setters/getters and method calls). These are synchronous. It would seem therefore that if the V8 in blink used by QWebEngineView had one extension added into it which is the equivalent of:

      var result = execQObjectMethod("object_id", "name", args....);

      then sync calls could be made back into Qt code. The host QWebEngineView would simply need two new methods e.g. registerQObject("object_id", Object*) and execQObjectMethod("name", args...). This would then enable the wrapper proxy to be a drop in replacement for QtWebView.

      Thoughts anyone? or has anyone done this already?

      1 Reply Last reply Reply Quote 0
      • First post
        Last post