On Fri, Jul 2, 2010 at 1:58 PM, Gustavo Sverzut Barbieri < [email protected]> wrote:
> On Fri, Jul 2, 2010 at 11:17 AM, Cedric BAIL <[email protected]> wrote: > > On Fri, Jul 2, 2010 at 3:44 PM, Gustavo Sverzut Barbieri > > <[email protected]> wrote: > >> On Fri, Jul 2, 2010 at 8:17 AM, Enlightenment SVN > >> <[email protected]> wrote: > >>> Log: > >>> * ephoto: use ecore_long_run instead of idler to do async > blocking IO. > >>> > >>> Author: cedric > >>> Date: 2010-07-02 04:17:59 -0700 (Fri, 02 Jul 2010) > >>> New Revision: 49995 > >>> > >>> Modified: > >>> trunk/ephoto/src/bin/ephoto_thumb.c > trunk/ephoto/src/bin/ephoto_thumb_browser.c > >>> > >>> Modified: trunk/ephoto/src/bin/ephoto_thumb.c > >>> =================================================================== > >>> --- trunk/ephoto/src/bin/ephoto_thumb.c 2010-07-02 11:15:20 UTC (rev > 49994) > >>> +++ trunk/ephoto/src/bin/ephoto_thumb.c 2010-07-02 11:17:59 UTC (rev > 49995) > >>> @@ -136,6 +136,9 @@ > >>> NULL, > >>> NULL, > >>> NULL, > >>> + NULL, > >>> + NULL, > >>> + NULL, > >>> NULL > >>> }; > >> > >> no, avoid these fixes. Move it to use the macro instead. The macro > >> will avoid having to do these fixes in the future. > >> > >> Okra: also, please consider looking in evas's box/table smart objects, > >> and clipped smart object. They will likely save you time. And use the > >> Evas_Smart_Class::calculate instead of your configure. To mark it as > >> changed to have this method call before render time, just call > >> evas_object_smart_changed() > > > > I will let okra just fix that one. > This(ephoto_thumb) is something that I basically just copy/pasted from e's widget image when I was looking for a quick solution prior to elm existing... what I will likely do is just get rid of ephoto_thumb and use an elm_bg widget and swallow that into the elm_layout widget instead of ephoto_thumb. > > > >>> + while ((d = readdir(ed->direc))) > >>> + { > >>> + if (ecore_thread_check(thread)) break; > >>> + > >>> + path = malloc(sizeof (char) * > >>> + (strlen(ed->dir) + 2 + > strlen(d->d_name))); > >>> + if (!path) continue; > >>> + > >>> + strcpy(path, ed->dir); > >>> + strcat(path, "/"); > >>> + strcat(path, d->d_name); > >> > >> ouch, this is not good... check how it is done in ecore_file, > >> basically you know the first part (ed->dir + '/') is invariant, so > >> save it, then override the last part and knowing the full size (with > >> d_name) you malloc + memcpy, it is faster as you do bigger copies at > >> once, code will be simpler as well. strcat needs to walk it to the > >> end, so it is stupid to call it. > > > > Just a quick written piece of code before I find a proper solution. > > > >> Maybe ecore_file_ls() could have a counterpart like > >> ecore_file_ls_iterator(), then we can benefit from its code and be > >> able to abort until it gets to the end? > > > > Good idea, I was thinking about doing just that. And it's a good thing > > to remember us we should use more iterator and accessor. > > > >>> + type = efreet_mime_type_get((const char *)path); > >> > >> cedric, I really don't think efreet mime_type_get() is thread-safe :-/ > > > > Well I followed as much path I could in the code, and it seems to be > > safe, but yes, I agree I have no garanty. But I would prefer to fix > > this the other way around, if possible without increasing Efreet cost > > to make it thread safe. > > > >> maybe move this to the main thread? > > > > Do you know if elementary does call efreet in the background ? If not, > > then that's the only current user in ephoto, and their is only one > > thread running, so safe for the moment. > > It can call. Just send the files unchecked to main thread, then check > with efreet there and ignore paths there. > > BR, > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
