Having had a discussion with Kenneth, came to the following Ewk_View refactoring plan: 1) Existing EwkViewImpl class code and Ewk_view smart object code will be distributed between two new classes: WebView and EwkView 2) WebView class will be located inside WebKit2 folder (uiprocess/efl). This class is intended to be minimal and just expose the WK2 internals we need; it will be EFL-agnostic meaning we avoid Evas constructs in it. 3) WebView class will not be exported, instead it will have exported wrapping C WKView API(api/c/efl), including client API. 4) EwkView class will be located outside of WebKit2 folder. This class will include the glue code between EFL (Evas) and WebView. Besides EwkView will support WebView client interface.

(In reply to comment #1) > Having had a discussion with Kenneth, came to the following Ewk_View refactoring plan: > 1) Existing EwkViewImpl class code and Ewk_view smart object code will be > distributed between two new classes: WebView and EwkView > > 2) WebView class will be located inside WebKit2 folder (uiprocess/efl). > This class is intended to be minimal and just expose the WK2 internals we need; it will be EFL-agnostic meaning we avoid Evas constructs in it. > > 3) WebView class will not be exported, instead it will have exported wrapping C WKView API(api/c/efl), including client API. > > 4) EwkView class will be located outside of WebKit2 folder. This class will include the glue code between EFL (Evas) and WebView. Besides EwkView will > support WebView client interface. Why does EwkView need to be outside the WebKit2 folder?

(In reply to comment #2) > (In reply to comment #1) > > Having had a discussion with Kenneth, came to the following Ewk_View refactoring plan: > > 1) Existing EwkViewImpl class code and Ewk_view smart object code will be > > distributed between two new classes: WebView and EwkView > > > > 2) WebView class will be located inside WebKit2 folder (uiprocess/efl). > > This class is intended to be minimal and just expose the WK2 internals we need; it will be EFL-agnostic meaning we avoid Evas constructs in it. > > > > 3) WebView class will not be exported, instead it will have exported wrapping C WKView API(api/c/efl), including client API. > > > > 4) EwkView class will be located outside of WebKit2 folder. This class will include the glue code between EFL (Evas) and WebView. Besides EwkView will > > support WebView client interface. > > Why does EwkView need to be outside the WebKit2 folder? It will be in UIProcess/API/efl so not actually outside WebKit2 folder, but in the EFL-API area.

(In reply to comment #1) > Having had a discussion with Kenneth, came to the following Ewk_View refactoring plan: > 1) Existing EwkViewImpl class code and Ewk_view smart object code will be > distributed between two new classes: WebView and EwkView It looks this is meaningful work only when we decide to move APIs to Source/WebKit/efl-wk2, right ?

(In reply to comment #4) > (In reply to comment #1) > > Having had a discussion with Kenneth, came to the following Ewk_View refactoring plan: > > 1) Existing EwkViewImpl class code and Ewk_view smart object code will be > > distributed between two new classes: WebView and EwkView > > It looks this is meaningful work only when we decide to move APIs to Source/WebKit/efl-wk2, right ? I would say that moving of EwkView out of WebKit2 folder should be done when we decide to move our APIs. The rest of work should be done at the moment, so that we fix holes in WK2 API layering.

Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.