September 2012 - webkit-efl - lists.webkit.org

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

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

24 Sep '12

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? BR, Eunmi Lee ------- Original Message ------- Sender : Dumez, Christophe<christophe.dumez(a)intel.com> Date : 2012-09-21 13:54 (GMT+09:00) Title : Re: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Hi, Why don't we go the other way around and remove the initialization code from RunLoopEfl? We already have dedicated ewk_init/shutdown functions, I don't see why we would rely on RunLoop to do the initialization for us. Kr, Chris. On Fri, Sep 21, 2012 at 5:28 AM, Kangil Han <kangil.han(a)samsung.com> wrote: Hi Eunmi, I also agree with your opinion. This would be a little bit new rule to programmers who are used to declare initialize/finalize pattern. However, w/o this pattern looks more clean and creative to me. Thanks! - Kangil Han -----Original Message----- From: webkit-efl-bounces(a)lists.webkit.org [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of EunMi Lee Sent: Thursday, September 20, 2012 9:48 PM To: webkit-efl(a)lists.webkit.org Subject: [webkit-efl] Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp Dear webkit-efl folks, I'm writing to discuss about ewk_{init, shutdown} that are doing duplicated works with RunLoopEfl.cpp. We initialize and shutdown the ecore, ecore_evas, ecore_file and edje in the RunLoopEfl's constructor and destructor. so, I think we can remove duplicated works from the ewk_{init, shutdown}. The ewk_{init, shutdown} also have codes to intialize g_type and glib, and we can move them to the RunLoopEfl. In the WebKit2/EFL, we have WebContext which is created before creating ewk_view and RunLoop is created when we create first WebContext. That means we have a location to initialize and shutdown the efl libraries that are used in the ewk - RunLoop. so, we don't have to add ewk_{init, shutdown} API like WebKit1/EFL. Additionally, I don't want to force applications to call ewk_{init, shutdown} before and after using ewk. We have no choice but to use ewk_{init, shutdown} APIs in the WebKit1/EFL, but we can use RunLoopEfl in the WebKit2/EFL. I've created new bug for this work, but I want to listen your opinions before making patch. https://bugs.webkit.org/show_bug.cgi?id=97173 BR, Eunmi Lee _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

3 5

Enabling CSS Regions
by Dominik Röttsches 24 Sep '12

24 Sep '12

Hi, I would like to default enable CSS regions and volunteer for maintaining the EFL aspects of it, like occasional rebaselining when the feature moves forward. https://bugs.webkit.org/show_bug.cgi?id=83897 Please let me know if there are any objections, otherwise I would go forward and try landing the above patch that enables the feature. Regards, Dominik

3 2

Removing ewk_{init, shutdown}'s duplicated works with RunLoopEfl.cpp
by EunMi Lee 21 Sep '12

21 Sep '12

Dear webkit-efl folks, I'm writing to discuss about ewk_{init, shutdown} that are doing duplicated works with RunLoopEfl.cpp. We initialize and shutdown the ecore, ecore_evas, ecore_file and edje in the RunLoopEfl's constructor and destructor. so, I think we can remove duplicated works from the ewk_{init, shutdown}. The ewk_{init, shutdown} also have codes to intialize g_type and glib, and we can move them to the RunLoopEfl. In the WebKit2/EFL, we have WebContext which is created before creating ewk_view and RunLoop is created when we create first WebContext. That means we have a location to initialize and shutdown the efl libraries that are used in the ewk - RunLoop. so, we don't have to add ewk_{init, shutdown} API like WebKit1/EFL. Additionally, I don't want to force applications to call ewk_{init, shutdown} before and after using ewk. We have no choice but to use ewk_{init, shutdown} APIs in the WebKit1/EFL, but we can use RunLoopEfl in the WebKit2/EFL. I've created new bug for this work, but I want to listen your opinions before making patch. https://bugs.webkit.org/show_bug.cgi?id=97173 BR, Eunmi Lee

3 2

Re: [webkit-efl] Log macro support for EINA_LOG_DOM_XXX series
by 송진우 20 Sep '12

20 Sep '12

3 2

Re: [webkit-efl] Log macro support for EINA_LOG_DOM_XXX series
by Jinwoo Song 20 Sep '12

20 Sep '12

I agree that WARN and INFO are more clear and consistent name. Then I'll create a bug to change the macro name in WebKit1 and WebKit2. Thanks for feedback, Kenneth. :) Jinwoo ------- Original Message ------- Sender : Kenneth Rohde Christiansen<kenneth.christiansen(a)gmail.com> Date : 2012-09-20 02:47 (GMT+09:00) Title : Re: [webkit-efl] Log macro support for EINA_LOG_DOM_XXX series So why are you using WRN and not WARN, INF and not INFO? The latter seems better and more consistent Kenneth On Wed, Sep 19, 2012 at 7:02 AM, Jinwoo Song wrote: > Dear webkit-efl developers, > > I'd like to notice you the newerly added log macros which wrap the EINA_LOG_DOM_XXX series. > http://trac.webkit.org/changeset/128962 > > #define CRITICAL(...) EINA_LOG_DOM_CRIT(_ewk_log_dom, __VA_ARGS__) > #define ERR(...) EINA_LOG_DOM_ERR(_ewk_log_dom, __VA_ARGS__) > #define WRN(...) EINA_LOG_DOM_WARN(_ewk_log_dom, __VA_ARGS__) > #define INF(...) EINA_LOG_DOM_INFO(_ewk_log_dom, __VA_ARGS__) > #define DBG(...) EINA_LOG_DOM_DBG(_ewk_log_dom, __VA_ARGS__) > > As you konw, the EINA_LOG_DOM_XXX logs a message on the speicified domain and format. > In webkit2, 'ewebkit2' domain is registered in ewk_init(), so if you want to use the 'ewebkit2' domain for the error log, > you can just use the simple log macros. > > Actually, the macro names came from the webkit1, but IMO, it seems to be better to align with EINA_LOG's names. > If you have ideas or feedback, please let me know. :) > > Thanks, > Jinwoo > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆

1 0

Log macro support for EINA_LOG_DOM_XXX series
by Jinwoo Song 19 Sep '12

19 Sep '12

Dear webkit-efl developers, I'd like to notice you the newerly added log macros which wrap the EINA_LOG_DOM_XXX series. http://trac.webkit.org/changeset/128962 #define CRITICAL(...) EINA_LOG_DOM_CRIT(_ewk_log_dom, __VA_ARGS__) #define ERR(...) EINA_LOG_DOM_ERR(_ewk_log_dom, __VA_ARGS__) #define WRN(...) EINA_LOG_DOM_WARN(_ewk_log_dom, __VA_ARGS__) #define INF(...) EINA_LOG_DOM_INFO(_ewk_log_dom, __VA_ARGS__) #define DBG(...) EINA_LOG_DOM_DBG(_ewk_log_dom, __VA_ARGS__) As you konw, the EINA_LOG_DOM_XXX logs a message on the speicified domain and format. In webkit2, 'ewebkit2' domain is registered in ewk_init(), so if you want to use the 'ewebkit2' domain for the error log, you can just use the simple log macros. Actually, the macro names came from the webkit1, but IMO, it seems to be better to align with EINA_LOG's names. If you have ideas or feedback, please let me know. :) Thanks, Jinwoo

2 1