Bug 59922

Created attachment 91901 [details] Patch

Comment on attachment 91901 [details] Patch LGTM.

The commit-queue encountered the following flaky tests while processing attachment 91901 [details]: http/tests/xmlhttprequest/xmlhttprequest-50ms-download-dispatch.html bug 52016 (author: jchaffraix@webkit.org) The commit-queue is continuing to process your patch.

Comment on attachment 91901 [details] Patch Clearing flags on attachment: 91901 Committed r85471: <http://trac.webkit.org/changeset/85471>

All reviewed patches have been landed. Closing bug.

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.

(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

(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.

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

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>

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

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