Changes between Version 13 and Version 14 of QtWebKitForQt5


Ignore:
Timestamp:
Jun 11, 2012 12:14:55 AM (12 years ago)
Author:
Simon Hausmann
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • QtWebKitForQt5

    v13 v14  
    2222
    2323   * Our focus should be on making the WebKit2 port fast and stable enough for a web browser.
    24    * A QML based UI component offers built-in handling for gestures, touch events (and scrollbars?).
     24   * A QML based UI component offers built-in handling for gestures, touch events and viewport meta tag.
    2525   * We should not spend time designing APIs that allow for feature combinations or software fallbacks that don't make sense. Features like WebGL or video should either work out of the box properly accelerated or be disabled.
    2626   * The QWidget/QGraphicsView based WebKit1 API moves into a separate shared library that links against QtWebKit.
    … …  
    7676   * Change the corresponding media player back-end to render into such texture-backed layers.
    7777   * Implement support on the UI process side for establishing the UI for the temporary root layer for fullscreen elements. (maybe a dedicated QWindow subclass that renders straight with a dedicated GL texturemapper instance that small tree of texture mapper nodes that represent the layers of the fullscreen element hierarchy)
    78 
    79 === JavaScript ===
    80 
    81 QtWebKit for Qt 5 uses V8 as the underlying JS engine. The implementation of QObject bindings needed for WebKit1 as well as potentially for WebKit2's
    82 WebProcess should be implemented in either in the QtScript library (based on V8) or another library in Qt that provides equivalent functionality.
    83 
    84 ----
    85 Jocelyn: This is long term stuff, but since we want to have the main interface as QML from a different process than the page's JS runtime, I think we should take the time to re-evaluate the benefits of exposing the engine using the QtScript API. This was a dream we had before WebKit2 was introduced.
    86 Chrome's extention are allowed to manipulate pages content using [http://code.google.com/chrome/extensions/content_scripts.html content scripts] and can communicate with the extension's script using [http://code.google.com/chrome/extensions/messaging.html messages]. Doing the same kind of stuff is one way I see how to prevent the developer from having to tediously load a C++ module in the web process.
    87 
    88 Simon: I agree, C++ modules are tedious compared to script injection. A direct export-QObject-pointer-to-JS API may not make sense anymore, but for compatibility I think
    89 we'll have to continue to offer that in the WebKit1 API library. That could still be done through V8 and QtScript-QObject bindings.
    90 
    91 === Discussion ===
    92 noamr: I think that this is a good direction. A big question yet to be answered is how much hybrid support we need going forward with WebKit2. If we enable QML with WebKit2, do we enable the javaScriptWindowObjects property? or do we go with something a bit different like allowing communication with the container via channel messaging?
    93 
    94 simon: I like the idea of a channel messaging as an API, especially when on the QML side the messages could be received in "onMessageReceived:" alike signal handlers
    95 and posted via QML's JavaScript.
    96 
    97 romaxa: WebGL option a) will require some double buffering -> additional tx->tx copy, also creation +1 GL context on WebProcess side, sounds like serialization is better way to go