2012/5/24 Carsten Haitzler <[email protected]>: > On Thu, 24 May 2012 00:25:09 -0300 Gustavo Sverzut Barbieri > <[email protected]> said: > >> You cannot cover all libraries as supposedly there will always be third party >> libs following that pattern. So far we can do many, but it's impossible to >> guarantee all. > > sure - and for those libraries - you need to follow their setup/shutdown > mechanisms. for efl we have covered it all for the user - as of elementary we > have.
The underyling assumption is that init/shutdown is properly used for all cases. But in some cases, it does not. :( There can exist so many libraries/applications/bugs/people to use EFL. We can not control all those things and people. Furthermore, in top level application developers's point of view, they should inspect all static/dynamic libraries they use and find bugs and send patches and wait those are fixed, and so on. This may be the best way theoretically. ;) So I want that EFL init/shutdown functions can manage these problems nicely. I mentioned this as previous mail (http://www.mail-archive.com/[email protected]/msg41502.html). I do not know exactly where return value of init/shutdown is used for. Actually current counter value does not check whether init/shutdown is called or not if init/shutdown is not used properly/correctly as we expected. Also almost documentations do not warn or remark users about this. So IMHO, I suggest that init/shutdown are better to be changed to support disordered usage. Or at least documentation should warn/remark about that. >> --Gustavo >> >> Sent from my iPhone >> >> On 24/05/2012, at 00:20, Carsten Haitzler (The Rasterman) >> <[email protected]> wrote: >> >> > 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 >> > > > -- > ------------- 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 -- BRs, Kim. ------------------------------------------------------------------------------ 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
