Bug 59922 – [EFL] Cleanup EFL initialization/shutdown in the EWebLauncher

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit EFL

[Tomasz Morawski]

Removed ecore_evas_init and edje_init form main function due to they 
are also called in the ewk_init. Moved ewk_shutdown to quit function.

[Tomasz Morawski]

Created attachment 91901 [details]
Patch

[Gyuyoung Kim]

Comment on attachment 91901 [details]
Patch

LGTM.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 91901 [details]:

http/tests/xmlhttprequest/xmlhttprequest-50ms-download-dispatch.html bug 52016 (author: [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 91901 [details]
Patch

Clearing flags on attachment: 91901

Committed r85471: <http://trac.webkit.org/changeset/85471>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Lucas De Marchi]

The rule of thumb in EFL is that you init in all the places you use it. So, if in your application you call ecore_evas_* functions, you have to call ecore_evas_init() first.

All the EFL init functions will just increment a ref if they are already initialized. This is the easiest way to keep things safe and is the way adopted in all the rest of EFL.


So, ewk calls ecore_evas_init() and edje_init() because it uses functions of these libraries. In your application, you shouldn't trust what the library will do with external libraries, so you should call the _init() function too. As I said, this will be almost a nop and you'll be safe regarding future updates.

[Tomasz Morawski]

(In reply to comment #6)
> The rule of thumb in EFL is that you init in all the places you use it. So, if in your application you call ecore_evas_* functions, you have to call ecore_evas_init() first.
> 
> All the EFL init functions will just increment a ref if they are already initialized. This is the easiest way to keep things safe and is the way adopted in all the rest of EFL.
> 
> 
> So, ewk calls ecore_evas_init() and edje_init() because it uses functions of these libraries. In your application, you shouldn't trust what the library will do with external libraries, so you should call the _init() function too. As I said, this will be almost a nop and you'll be safe regarding future updates.

Thank you for your comment. Generally I agre with you. This is a good way. 
But in this specific case where we use our own _WebKit engine library_ this redundant initialization makes only code confusion. We exactly know what initialization function will do and it is hard to belive that the EFL initialization code will disappears from there. :) Moreover, when I use an engine I expect that a lot of think like initializations will be done on the engine site without my control. On the other hand why there are functions like ewk_init and ewk_shutdown in the public api and the browser programmer have to call another initalization for objects that are belogns to him only for increase ref counter. 

Should we also move glib initialization to EWebLauncher to be consistent? :)

Best Regards 
Tomasz Morawski

[Lucas De Marchi]

(In reply to comment #7)
> Thank you for your comment. Generally I agre with you. This is a good way. 
> But in this specific case where we use our own _WebKit engine library_ this 

What do you mean by "our own webkit engine library"? Besides being a browser for testing the EFL port, EWebLauncher serves as a demo how a browser would be done with this port.

> redundant initialization makes only code confusion. We exactly know what 

Why? This is a common agreement among EFL developers: you init what you use. If your application uses evas, you init evas; if it uses ecore_evas, you init ecore_evas... even if evas is actually initialized by ecore_evas_init().

> initialization function will do and it is hard to belive that the EFL
> initialization code will disappears from there. :) Moreover, when I use an
> engine I expect that a lot of think like initializations will be done on the
> engine site without my control.

Exactly because it's without your control, you shouldn't trust it.


> 
> Should we also move glib initialization to EWebLauncher to be consistent? :)

If you use a function in glib's namespace, I'd say yes.

[Tomasz Morawski]

Thank you for your explanation. I know what I have done wrong. Could you revert my commit?

[Lucas De Marchi]

Reverted r85471 for reason:

The rule of thumb in EFL is that you init in all the places you use it. So, if in your application you call ecore_evas_* functions, you have to call ecore_evas_init() first.

Committed r85625: <http://trac.webkit.org/changeset/85625>

[Raphael Kubo da Costa (:rakuco)]

Hey there, wouldn't it make sense to close this bug now?

[Lucas De Marchi]

(In reply to comment #11)
> Hey there, wouldn't it make sense to close this bug now?

Yes, closing it now.