- webkit-efl - lists.webkit.org

Naming rules for setting APIs
by Jinwoo Song 10 Oct '12

10 Oct '12

Hi, I'm revisiting API names and documentation of WebKit2 EFL settings. https://bugs.webkit.org/show_bug.cgi?id=98793 Currently, there is no concrete rules for API naming, so the names are inconsistent. For example: ewk_settings_enable_frame_flattening_set()/ewk_settings_enable_frame_flattening_get() vs. ewk_settings_developer_extras_enabled_set()/ewk_settings_developer_extras_enabled_get() Grzegorz suggested to use 'ewk_settings_enable_frame_flattening_set() with following rules and I also prefer this one. > 1) WK1 uses similar API, for example: ewk_view_setting_enable_frame_flattening_set > 2) Verb next to another verb (enabled_set) doesn't looks/sounds well. > 3) I'd rather prefer not using plural in API (enabled -> enable) > 4) The Spelling API bug 91854 proposes API syntax based on above suggestions (as during work on this there wasn't ewk2-settings yet). So we will have consistent API. FYI, GTK uses set_enable_frame_flattening() and Qt uses setFrameFlatteningEnabled(). So I'd like to here the opinions for the naming rule and if there is no objections for the suggested rule, I'll adjust the APIs with this one. Thanks, Jinwoo

5 6

Porting MiniBrowser to Elementary
by Dumez, Christophe 10 Oct '12

10 Oct '12

Hi, I'm writing to notify WebKit2 EFL developers that I am porting MiniBrowser to Elementary [1] and my patch is almost ready for review. MiniBrowser is an application and Elementary brings a lot of functionality (widgets, layouts, dialogs, ...) that is extremely useful to applications. The idea is to bring Elementary as an optional dependency and build MiniBrowser only if Elementary library is found. My initial patch will not add any new controls and will simply port the existing code to Elementary. This will make the code simpler though the use of layouts and an Elementary Entry widget for the URL bar. As a side effect, the URL bar will finally supports copy / paste. In the near future, Elementary will help bring more functionality such as: - Back / Refresh / Home buttons - Alert / Prompt / Confirmation windows - Tabs - ... Please tell me if you have any feedback regarding this change. [1] http://docs.enlightenment.org/auto/elementary/index.html Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

6 15

Re: [webkit-efl] Porting MiniBrowser to Elementary
by Kangil Han 10 Oct '12

10 Oct '12

Hi, I am still confused. Suppose I am a developer who is using efl-wk2 for commercializing project. Then, I find efl-wk2 shouldn't have elementary dependency because of package layer violation. However, without elementary package, I couldn't launch test program called MiniBrowser. Does this make sense? Kind regards, Kangil From: ryuan Choi [mailto:ryuan.choi@gmail.com] Sent: Wednesday, October 10, 2012 9:59 AM To: kangil.han(a)samsung.com Subject: Re: [webkit-efl] Porting MiniBrowser to Elementary His latest change just checks elementary as an optional. So, I think that webkit/efl package can avoid to include elementary package. If elementary is not available, only minibrowser will not be built. Chris, If this is acceptable for efl folks, do you have a plan to fix Eweblauncher also? Best Regards, Ryuan Choi 2012/10/10 Kangil Han <kangil.han(a)samsung.com> Hi Chris, I have a concern on below change. AFAIK, elementary, especially webview, has dependency on WebKit library. So, below change will definitely incur package cross dependency. I would prefer that you have deep discussion with EFL people on this. Kind regards, Kangil From: webkit-efl-bounces(a)lists.webkit.org [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of Dumez, Christophe Sent: Wednesday, October 10, 2012 1:43 AM To: webkit-efl(a)lists.webkit.org Subject: Re: [webkit-efl] Porting MiniBrowser to Elementary Hi, I uploaded the patch to: https://bugs.webkit.org/show_bug.cgi?id=98748 Kr, On Tue, Oct 9, 2012 at 7:30 PM, Dumez, Christophe <christophe.dumez(a)intel.com> wrote: Hi, I'm writing to notify WebKit2 EFL developers that I am porting MiniBrowser to Elementary [1] and my patch is almost ready for review. MiniBrowser is an application and Elementary brings a lot of functionality (widgets, layouts, dialogs, ...) that is extremely useful to applications. The idea is to bring Elementary as an optional dependency and build MiniBrowser only if Elementary library is found. My initial patch will not add any new controls and will simply port the existing code to Elementary. This will make the code simpler though the use of layouts and an Elementary Entry widget for the URL bar. As a side effect, the URL bar will finally supports copy / paste. In the near future, Elementary will help bring more functionality such as: - Back / Refresh / Home buttons - Alert / Prompt / Confirmation windows - Tabs - ... Please tell me if you have any feedback regarding this change. [1] http://docs.enlightenment.org/auto/elementary/index.html Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

WebKit2 EFL API consistency: uri vs url
by Dumez, Christophe 08 Oct '12

08 Oct '12

Hi, Our WebKit2 EFL API is currently a bit inconsistent in its use of uri / url. Some functions use one, some use the other. The majority seems to use url though. I'm proposing that we rename uri to url in all the WebKit2 EFL APIs and documentation, for the sake of consistency. if you disagree with this change, speak now or forever hold your peace :) Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

4 6

How about switching backing store of DRT to single?
by ryuan Choi 08 Oct '12

08 Oct '12

Dear webkit-efl developers, I want your opinion about switching default backing store of DRT(DumpRenderTree/Efl) to `single` instead of `tiled`. Now, default is `tiled` and DRT_USE_SINGLE_BACKING_STORE environment is used to switch. As you may know, DRT/Efl can not pass some pixel tests. Although it is because of many bugs, I think that one of major reason is that DRT/Efl calls paint() directly instead of capturing. So I created https://bugs.webkit.org/show_bug.cgi?id=79853 but it was reverted because of many regressions. In my poor analyze, webkit/efl can not capture the webivew now because webkit/efl does not draw mockScrollbar as calling paintContents() instead of paint() One simple solution is adding logic to paint scrollbar in _ewk_view_tiled_render_cb (ewk_view_tiled.cpp) But, I am not sure that painting scrollbar for DRT in tile is reasonable. When we designed tiled backingstore, we focused performance and I think that painting scrollbar is not a role of tile. Instead, I suggest using ewk_view_single for DRT. ewk_view_single is simple and similar with other ports. I think that ewk_view_single is more suitable for layout test. Could you let me know your opinion? Regards, Ryuan Choi

3 3

Fwd: Re: Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp
by EunMi Lee 05 Oct '12

05 Oct '12

Dear all, I have to say that I can not change ewk_{init, shutdown} to local function from API, because ecore should be initialized before using ecore_pipe with latest ecore library. The ecore_pipe starts to use eina_mempool to allocate the memory recently, and eina_init is done in the ecore_init, so we have to call ecore_init before using ecore_pipe. The ecore_pipe is created in the Source/WTF/wtf/efl/MainThreadEfl.cpp's initializeMainThreadPlatform(), initializeMainThreadPlatform() is called when we use the WKString and the WKString is used in the WebKitTestRunner before creating WebContext. So, I will maintain the ewk_{init, shutdown} as an API and prepare patch for that again. https://bugs.webkit.org/show_bug.cgi?id=97173 BR, Eunmi Lee ------- Original Message ------- Sender : 이은미<eunmi15.lee(a)samsung.com> S4(선임)/선임/차세대Computing Lab(S/W센터)/삼성전자 Date : 2012-09-25 11:16 (GMT+09:00) Title : Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Dear Kangil and Chris, Both of you want to process {init, shutdown} in the webkit, not applications. :) I will prepare patch for that. Thanks, Eunmi Lee ------- Original Message ------- Sender : 한강일 S5(책임)/책임/차세대S/W개발그룹(무선)/삼성전자 Date : 2012-09-24 19:18 (GMT+09:00) Title : RE: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Chris, I’ve consistently expressed my opinion from the application side point of view. It is true that ewk_context does initializing stuff. However, in application, we can just trigger ewk_view_add. This looks great on my side. - Kangil Han From: Dumez, Christophe [mailto:christophe.dumez@intel.com] Sent: Monday, September 24, 2012 4:30 PM To: kangil.han(a)samsung.com Cc: eunmi15.lee(a)samsung.com; webkit-efl(a)lists.webkit.org Subject: Re: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Kangil, I don't understand your point. As Eunmi said, it makes more sense to do the Ewk initialization in ewk_context. Doing the Ewk initialization in ewk_view may be problematic because the client can create a ewk_context before creating a ewk_view. However, it is impossible to construct a ewk_view without a ewk_context being constructed first. The ewk_view constructor will start by creating a ewk_context if it is not provided with one. Kr, On Mon, Sep 24, 2012 at 10:20 AM, Kangil Han wrote: I vote to ‘by contructing a view’! From: Dumez, Christophe [mailto:christophe.dumez@intel.com] Sent: Monday, September 24, 2012 4:07 PM To: eunmi15.lee(a)samsung.com Cc: 한강일; webkit-efl(a)lists.webkit.org Subject: Re: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp On Mon, Sep 24, 2012 at 9:12 AM, EunMi Lee wrote: Dear Chris and webkit-efl folks, I've got your point and we have no reason to rely on RunLoop to do the initialization. We just need "location" to do initialization for EFL. I don't matter to use ewk_{init,shutdown} or RunLoop, but I don't want to force applications to call ewk_{init, shutdown}. In the WK1, applications should use ewk_{init, shutdown} API but in the WK2 we can do that inside webkit becasue we have ewk_context which is careted before creating ewk_view. In conclusion, my opinions are as follows, - Use ewk_{init, shutdown} to do initialization. (because there is no reason to rely on RunLoop and we already have ewk_{init, shutdown}) - Do not open ewk_{init, shutdown} as an API and just call in the ewk_context. (in order to not force applications to call them) How do you think? I don't have any strong objection against moving the Ewk initialization code to ewk_context. It is a bit less error prone and hopefully, the client will not call any ewk function before a context initialized (either explicitly or by constructing a view). Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

Re: [webkit-efl] How about removing redundant "web" word from ewk_web_error_XXX APIs for webkit2
by 양종석 27 Sep '12

27 Sep '12

1 0

How about removing redundant "web" word from ewk_web_error_XXX APIs for webkit2
by JongSeok Yang 27 Sep '12

27 Sep '12

Dear webkit-efl developers, I'd like to discuss about "web" word for ewk APIs that is redundant word. As you know, "ewk" means "EFL WebKit" and ewk APIs don't have "web" word. For example, webview APIs for EFL port are ewk_view_XXX instead of ewk_web_view_XXX. And you can check the orignal WK APIs for ewk_web_error APIs like the below: WK_EXPORT WKStringRef WKErrorCopyWKErrorDomain(); WK_EXPORT WKStringRef WKErrorCopyDomain(WKErrorRef error); WK_EXPORT int WKErrorGetErrorCode(WKErrorRef error); WK_EXPORT WKURLRef WKErrorCopyFailingURL(WKErrorRef error); WK_EXPORT WKStringRef WKErrorCopyLocalizedDescription(WKErrorRef error); So, I think that we should remove "web" word from ewk_web_error_XXX APIs for webkit2. I'll created new bug for this work. Could you let me know your opinion? BR, Jongseok Yang.

3 2

Why don't we use Eina_Bool in unit test when testing public APIs ?
by Gyuyoung Kim 25 Sep '12

25 Sep '12

Hi EFL folks, I would like to discuss EINA_TRUE / FALSE usage in unit test. As you folks know, we have used *standard boolean* type except for public API and efl callback function. However, in my humble opinion, it would be good to use Eina_Bool in unit test when we test public APIs. Because EFL application will use Eina_Bool instead of standard boolean. Almost existing unit test cases are using Eina_Bool, for example, in test_ewk2_view.cpp. TEST_F(EWK2UnitTestBase, ewk_view_mouse_events_enabled) { ASSERT_TRUE(ewk_view_mouse_events_enabled_set(webView(), EINA_TRUE)); ASSERT_TRUE(ewk_view_mouse_events_enabled_get(webView())); ASSERT_TRUE(ewk_view_mouse_events_enabled_set(webView(), 2)); ASSERT_TRUE(ewk_view_mouse_events_enabled_get(webView())); ASSERT_TRUE(ewk_view_mouse_events_enabled_set(webView(), EINA_FALSE)); ASSERT_FALSE(ewk_view_mouse_events_enabled_get(webView())); } I'd like to listen EFL folks opinion. If there is no objection, I will add this to EFL coding style guidance. Cheers, -- Gyuyoung Kim SW Engineer, WebKit EFL Email : gyuyoung.kim at webkit.org Phone : +82 10 9530 0209

5 8

Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp
by EunMi Lee 25 Sep '12

25 Sep '12

Dear Kangil and Chris, Both of you want to process {init, shutdown} in the webkit, not applications. :) I will prepare patch for that. Thanks, Eunmi Lee ------- Original Message ------- Sender : 한강일<kangil.han(a)samsung.com> S5(책임)/책임/차세대S/W개발그룹(무선)/삼성전자 Date : 2012-09-24 19:18 (GMT+09:00) Title : RE: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Chris, I’ve consistently expressed my opinion from the application side point of view. It is true that ewk_context does initializing stuff. However, in application, we can just trigger ewk_view_add. This looks great on my side. - Kangil Han From: Dumez, Christophe [mailto:christophe.dumez@intel.com] Sent: Monday, September 24, 2012 4:30 PM To: kangil.han(a)samsung.com Cc: eunmi15.lee(a)samsung.com; webkit-efl(a)lists.webkit.org Subject: Re: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Kangil, I don't understand your point. As Eunmi said, it makes more sense to do the Ewk initialization in ewk_context. Doing the Ewk initialization in ewk_view may be problematic because the client can create a ewk_context before creating a ewk_view. However, it is impossible to construct a ewk_view without a ewk_context being constructed first. The ewk_view constructor will start by creating a ewk_context if it is not provided with one. Kr, On Mon, Sep 24, 2012 at 10:20 AM, Kangil Han <kangil.han(a)samsung.com> wrote: I vote to ‘by contructing a view’! From: Dumez, Christophe [mailto:christophe.dumez@intel.com] Sent: Monday, September 24, 2012 4:07 PM To: eunmi15.lee(a)samsung.com Cc: 한강일; webkit-efl(a)lists.webkit.org Subject: Re: Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp On Mon, Sep 24, 2012 at 9:12 AM, EunMi Lee <eunmi15.lee(a)samsung.com> wrote: Dear Chris and webkit-efl folks, I've got your point and we have no reason to rely on RunLoop to do the initialization. We just need "location" to do initialization for EFL. I don't matter to use ewk_{init,shutdown} or RunLoop, but I don't want to force applications to call ewk_{init, shutdown}. In the WK1, applications should use ewk_{init, shutdown} API but in the WK2 we can do that inside webkit becasue we have ewk_context which is careted before creating ewk_view. In conclusion, my opinions are as follows, - Use ewk_{init, shutdown} to do initialization. (because there is no reason to rely on RunLoop and we already have ewk_{init, shutdown}) - Do not open ewk_{init, shutdown} as an API and just call in the ewk_context. (in order to not force applications to call them) How do you think? I don't have any strong objection against moving the Ewk initialization code to ewk_context. It is a bit less error prone and hopefully, the client will not call any ewk function before a context initialized (either explicitly or by constructing a view). Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

1 0