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()
> + 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.
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?
> + type = efreet_mime_type_get((const char *)path);
cedric, I really don't think efreet mime_type_get() is thread-safe :-/
maybe move this to the main thread?
--
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
