[Webkit-unassigned] [Bug 59922] [EFL] Cleanup EFL initialization/shutdown in the EWebLauncher

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 2 07:33:14 PDT 2011


--- Comment #7 from Tomasz Morawski <t.morawski at samsung.com>  2011-05-02 07:33:14 PST ---
(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

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list