Bug 107662 - [WK2][EFL] Ewk_View implementation should use C WK2 API and not C++ internals
Summary: [WK2][EFL] Ewk_View implementation should use C WK2 API and not C++ internals
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 107666 107719 107931 108062 108915 109053 109794 110216 110345 110463 110741 110753 110877 111075 111563 111591
Blocks: 107657
  Show dependency treegraph
 
Reported: 2013-01-23 04:16 PST by Mikhail Pozdnyakov
Modified: 2017-03-11 10:52 PST (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Pozdnyakov 2013-01-23 04:16:21 PST
SSIA
Comment 1 Mikhail Pozdnyakov 2013-01-23 12:17:56 PST
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.
Comment 2 Chris Dumez 2013-01-23 12:22:01 PST
(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?
Comment 3 Kenneth Rohde Christiansen 2013-01-23 14:09:11 PST
(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.
Comment 4 Gyuyoung Kim 2013-01-23 18:02:38 PST
(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 ?
Comment 5 Mikhail Pozdnyakov 2013-01-23 23:47:01 PST
(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.
Comment 6 Michael Catanzaro 2017-03-11 10:52:25 PST
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.