On Wed, 19 Jan 2011 21:48:26 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Wed, Jan 19, 2011 at 9:35 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Wed, 19 Jan 2011 12:54:06 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > >> On Wed, Jan 19, 2011 at 3:00 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Thu, 13 Jan 2011 11:35:10 +0900 WooHyun Jung <wh0705.j...@samsung.com> > >> > said: > >> > > >> >> Hello. I'm WooHyun Jung. > >> >> > >> >> One question about not calling elm_mod_shutdown in elm.c (in > >> >> edje_externals). > >> >> > >> >> I've tested with elementary_test and I checked elm_mod_init is called > >> >> when initiating. > >> >> > >> >> But elm_mode_shutdown was not called when elementary_test is terminated. > >> >> > >> >> By this situation elm_init is called twice but elm_shutdown is called > >> >> just once. > >> >> > >> >> Can anybody check about this ? > >> > > >> > partly a design problem with externals and layering (that cant get fixed > >> > without a total rethink of the whole externals thing), and partly an > >> > implementation issue of ALWAYs dumbly initting elm from the externals > >> > module when it's initted (as opposed to used) thus incrementing ref > >> > count for init for elm and thus never making elm_shutdown work because > >> > it keeps the init count (as module shutdown doesnt get called because > >> > edje is not shut down because of the extra init ref). i made it ref and > >> > unref per object instead so it gets called now. > >> > >> it could just be initialized when you query modules or when the module > >> is used. The former should just be used by editors such as Editje > >> anyway, so not a problem. The later is the regular use, and makes > >> sense to initialize it. > > > > i changed it to init elm on first elm external actually created and > > shtudown on last deleted - that fixes this specific issue, but that doesn't > > fix the inverted layering (where edje now depends on a higher level lib > > above it (elm) via an indirect module link that is abstracted away from the > > higher level lib - the window may not be an elm_win and thus cause problems > > - so normally you'd have app -> edje -> evas -> x11 for example, now it > > goes app -> edje -> elm -> edje -> evas -> x11 - works, but design-wise not > > very clean). > > > > also doesnt change the design break that edje externals cause in that now > > edje no longer has guarantees of working. i intended edje to be a "it > > always will work (only subject to your edje version being up to date enough > > to have all the newest features). externals breaks that where a .edj may or > > may not work right depending if an externals module is installed or not. > > Suggestions other than remove the external support? It's not used anywhere > atm. removal isnt an option indeed. problem is that it invites a feature that may not work for someone doing arbitrary design in edje. maybe edje_cc requiring an explicit "allow externals" option and explicitly listing the ones allowed - at least to make it more obvious (a bit like linking for ld). warning that "this may not work" "some externals require special behavior from the app - eg elm win as a parent"... not sure really. it just opens up if's and gotchas that were not there before and i actually hoped to never have. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
