[webkit-qt] API proposal for handling (some) hybrid use cases

[Kenneth Rohde Christiansen]

Hi Caio,

Great idea and I think pretty much along with what most of us have
been considering.

> I think this API would serve as a "functional" replacement of the
> features: (1), (3) and (4). Of course will demand some changes, but I
> think overall will reduce our API surface: we don't expose a
> QWebElement anymore, users are encouraged to write DOM manipulation
> code in JS and use WebScript {}.

These scripts are almost a kind of "workers"

> Another upside is that future (and current) WK2 browsers using WebKit
> can use P2 as a basis for extension mechanism. This will be really
> useful for
>
> One downside is that QObject bridge (4) was _very_ convenient API,
> however I argue that one can build upon the proposed API to have
> convenince wrapping of QObjects -- this could be even adopted by
> QtWebKit later.
>
> This proposal doesn't cover:
>
> 2) QWebElement::render(), in QtCS it was discussed the possibility of
> having a QML component "WebSlice", with a source property pointing to
> a WebView and a element property describing which HTML element to
> "slice" (in a syntax similar to QWebElement/jQuery).

I think we really need to look into the actual use-cases for this to
see what is the best solution, consider AC etc.

> 5) QNAM: Some discussion about special scheme handling was posted by
> Simon. The team here in INdT office also had some discussions about
> the possibilities of customizing the WebProcess.

I guess we should look into supporting web process plugins for the hybrid case.

> 6) QPixmap/QImage -> <img>. This is very bridge dependent.

web process plugins could possible solve this. I believe that for some
use-cases as those of Netflix, this is quite important.

> 7) QWidgets inside a page: do we have users for this?

Plugins are on the way out :-) Let's let this feature rest in piece.

> Even not covering those other cases, I think this API stands on its
> own and is useful. In summary:
>
> - exchange messages with the webpage JS environment
> - and with isolated environments that we can create and plug in the page
> - small API surface
> - people manipulate the DOM the same way they do in a webpage
>
> What do you guys think?

Great ideas :-)

Kenneth