On Wed, 23 May 2012 22:50:10 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> As I tried to explain you save lines of code, adds inconsistencies since > elementary will not be able to cover everything. Unfortunately we disagree on > the best approach. it already covers all of core efl. when there is a single efl tree it'll cover everything in that tree. it wont be inconsistent. it's already pretty consistent. > --Gustavo > > Sent from my iPhone > > On 23/05/2012, at 21:04, Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Wed, 23 May 2012 13:03:42 -0300 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> On Wed, May 23, 2012 at 7:49 AM, Carsten Haitzler <[email protected]> > >> wrote: > >>> On Mon, 7 May 2012 19:09:45 +0900 (KST) Jiyoun Park <[email protected]> > >>> said: > >>> > >>> hmm realistically ecore_init and shutdown (same really with almost any efl > >>> api) is intended to be run ONCE per process and the shutdown once at > >>> process termination. not multiple times. it's a lot harder to make this > >>> always work in the repeated init/shutdown case and frankly was never > >>> intended for this or tested and implemented for it. my suggestion: only > >>> init once and shut down once. :) > >> > >> I know you wrote this based on an application writer point of view. > >> But given this is a generic mail list, please make the following > >> remark visible: > >> > >> - always init and shutdown ONCE per your CALL SITE usage. > >> > >> That means: if you write an app that uses ecore_* symbols, always call > >> ecore_init() and ecore_shutdown() from your app. Even if you get that > >> ecore_* from elementary_init()[1]. This consistency will save you > >> headaches in the future. And this rule easily applies to library, > >> being consistent everywhere. Actually it is the case to solve DSO > >> problems in linkage, pkg-config problems and so on. > >> > >> [1] I know many of us don't do ecore_init(), evas_init(), > >> eina_init()... and so on when using elementary_init(). Saves typing, > >> but is bad for consistency. If you explicitly use these symbols, as we > >> often do, then it's better to explicitly call them and avoid issues. > >> If you're experienced enough to skip them, do it but do not RECOMMEND > >> it to people :-) [if you don't call any ecore_evas_*, then there is > >> no need to ecore_evas_init()...] > > > > this isn't sustainable. then evewry app begins with a ridiculous list of > > inits: > > > > eina_init(); > > ecore_init(); > > evas_init(); > > edje_init(); > > elementary_init(); > > > > at a minimum.; if you have config of your own, need to deal with > > thumbnails, do some dbus and freedesktop stuff add: > > > > eet_init(); > > ethumb_init(); > > e_dbus_init(); > > efreet_init(); > > > > ... > > > > no - the POINT of elementary is to cut this out and bring down the barrier > > of entry to writing an app. you SHOULD use elm's main setup: > > > > #include <Elementary.h> > > > > EAPI_MAIN int elm_main(int argc, char **argv) > > { > > // if you want efl to handle finding your bin/lib/data dirs for u, you > > must // do this below. > > elm_app_info_set(elm_main, "datadir", "some-data-file"); > > elm_app_compile_bin_dir_set(PACKAGE_BIN_DIR); > > elm_app_compile_data_dir_set(PACKAGE_DATA_DIR); > > // do your setup code here - create window etc. no init/shutdown needed > > if // its a lib supported by elm, when done, we run. > > elm_run(); > > // do any application shutdown here > > elm_shutdown(); > > // final just before process shutdown stuff here > > // (after elm/rest of efl is done cleaning up) > > return 0; // app return code. 0 == no error > > } > > ELM_MAIN() > > > > i actually should make a simpler macro for the elm_main func decl. it's too > > much typing. the app info stuff could do with becoming part of some standard > > ptr/struct passed to elm. with all the inits you suggest to be used, and > > shutdowns, this template gets more than 2x longer with no actual gain in > > functionality. > > > >> -- > >> Gustavo Sverzut Barbieri > >> http://profusion.mobi embedded systems > >> -------------------------------------- > >> MSN: [email protected] > >> Skype: gsbarbieri > >> Mobile: +55 (19) 9225-2202 > >> > >> ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> enlightenment-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
