-
Notifications
You must be signed in to change notification settings - Fork 0
Cameo webview on tizen
Background: Discussions we had in Finland show that from the vast set of priorities and requirements we have for Cameo, one that remains relatively robust is that we want Cameo on Tizen. Practically this means that we want the Tizen usecases of the web stack, which is the Tizen HTML5 apps runtime and on the other hand the Tizen WebView usecases (WebView for EFL / OSP, plus potentially a better phonegap support for Tizen by creating a native EFL app which integrates such a WebView) to be implemented based on Chromium/Blink. Since both serve a slightly different purpose, and introducing a dependency, such as "the runtime should use the webview" would artificially slow us down, we deem it reasonable to just start prototyping a WebView for EFL based on Chromium's content API.
- A group of people in Finland will start sketching a proof of concept which shows a Chromium based WebView integrated into an EFL application. Focus is currently not on a clean API design, but mainly getting all the pieces in place and get a feel for what obstacles we face on the way.
- https://github.com/otcshare/cameo/wiki/Cameo-WebView-on-Tizen will as a start contain this email and some of the technical problems that we need to solve. Together we'll explore what other issues we need to solve and how we can jointly achieve the PoC outlined above.
In some sense, the EFL application embedding a Chromium web view turns into something like the UI process in the Chromium sense. We need all the parts on the EFL app side that do IPC to a renderer process. Establishing the IPC channel is a tricky process which in Chromium's architecture is closely linked with forking a process. It'd be best to solve this in a way so that the embedder of a Chromium based WebView does not have to change anything in her own main() function or similarly intrusive requirements.
Chromium's IPC supports message pumps based on several main loop frameworks such as Gtk and Qt. There is none for EFL per se, but it seems like the glib based mainloop/messagepump integration is acceptable for now.
In Chromium's architecture, the renderer process controls what happens to the WebView. From an EFL UI toolkit point of view, this should be the other way around - the toolkit decides what kind of screen space the WebView gets. This problem needs to be addressed on the way.