Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Bruno Dilly]

On Sat, Dec 8, 2012 at 7:21 AM, Enlightenment SVN
 wrote:
> Log:
> edje: use eo more.
>
>
> Author:   cedric
> Date: 2012-12-08 01:21:10 -0800 (Sat, 08 Dec 2012)
> New Revision: 80519
> Trac: http://trac.enlightenment.org/e/changeset/80519
>
> Modified:
>   trunk/edje/src/lib/edje_calc.c
>
> Modified: trunk/edje/src/lib/edje_calc.c
> ===
> --- trunk/edje/src/lib/edje_calc.c  2012-12-08 08:53:38 UTC (rev 80518)
> +++ trunk/edje/src/lib/edje_calc.c  2012-12-08 09:21:10 UTC (rev 80519)
> @@ -676,8 +676,9 @@
>
>  ed->recalc_hints = EINA_FALSE;
>
> -edje_object_size_min_calc(ed->obj, &w, &h);
> -evas_object_size_hint_min_set(ed->obj, w, h);
> +   eo_do(ed->obj,
> + edje_obj_size_min_get(&w, &h),
> + evas_obj_size_hint_min_set(w, h));

Hey Cedric, you are changin from size_min_calc to size_min_get here ^
Is this intended ?

>   }
>
> if (!ed->collection) return ;
> @@ -1230,9 +1231,9 @@
>tw = th = 0;
>if (!chosen_desc->text.min_x)
>  {
> -   evas_object_resize(ep->object, params->w, params->h);
> -   evas_object_textblock_size_formatted_get(ep->object, 
> &tw,
> -&th);
> +  eo_do(ep->object,
> +evas_obj_size_set(params->w, params->h),
> +evas_obj_textblock_size_formatted_get(&tw, &th));
>  }
>else
>  evas_object_textblock_size_native_get(ep->object, &tw, 
> &th);
> @@ -1257,8 +1258,9 @@
>   tw = th = 0;
>   if (!chosen_desc->text.max_x)
> {
> -  evas_object_resize(ep->object, params->w, params->h);
> -  evas_object_textblock_size_formatted_get(ep->object, &tw, 
> &th);
> + eo_do(ep->object,
> +   evas_obj_size_set(params->w, params->h),
> +   evas_obj_textblock_size_formatted_get(&tw, &th));
> }
>   else
> evas_object_textblock_size_native_get(ep->object, &tw, &th);
> @@ -1282,16 +1284,17 @@
>   double s = 1.0;
>
>   if (ep->part->scale) s = TO_DOUBLE(sc);
> - evas_object_scale_set(ep->object, s);
> - evas_object_textblock_size_formatted_get(ep->object, &tw, &th);
> +eo_do(ep->object,
> +  evas_obj_scale_set(s),
> +  evas_obj_textblock_size_formatted_get(&tw, &th));
>   if (chosen_desc->text.fit_x)
> {
>if ((tw > 0) && (tw > params->w))
>  {
> s = (s * params->w) / (double)tw;
> -   evas_object_scale_set(ep->object, s);
> -   evas_object_textblock_size_formatted_get(ep->object,
> -&tw, &th);
> +  eo_do(ep->object,
> +evas_obj_scale_set(s),
> +evas_obj_textblock_size_formatted_get(&tw, &th));
>  }
> }
>   if (chosen_desc->text.fit_y)
> @@ -1299,9 +1302,9 @@
>if ((th > 0) && (th > params->h))
>  {
> s = (s * params->h) / (double)th;
> -   evas_object_scale_set(ep->object, s);
> -   evas_object_textblock_size_formatted_get(ep->object,
> -&tw, &th);
> +  eo_do(ep->object,
> +evas_obj_scale_set(s),
> +evas_obj_textblock_size_formatted_get(&tw, &th));
>  }
> }
>}
> @@ -1373,8 +1376,9 @@
>  (!chosen_desc->text.max_x) && (!chosen_desc->text.max_y)))
>   return;
>
> -   evas_object_geometry_get(ep->object, NULL, NULL, &tw, &th);
> -   evas_object_text_style_pad_get(ep->object, &l, &r, &t, &b);
> +   eo_do(ep->object,
> +evas_obj_size_get(&tw, &th),
> +evas_obj_text_style_pad_get(&l, &r, &t, &b));
>
> mw = tw + l + r;
> mh = th + t + b;
> @@ -1533,9 +1537,10 @@
>  [(ep->part->effect & EDJE_TEXT_EFFECT_MASK_SHADOW_DIRECTION) 
> >> 4];
>   EVAS_TEXT_STYLE_SHADOW_DIRECTION_SET(style, shadow);
>
> - evas_object_text_style_set(ep->object, style);
> - evas_object_text_text_set(ep->object, text);
> - evas_object_geometry_get(ep->object, NULL, NULL, &tw, &th);
> +eo_do(ep->object,
> +  evas_obj_text_style_set(style),
> +  evas_obj_text_text_set(text),
> +  evas_obj_size_

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[ChunEon Park]

If you hope that, then fix all the bugs and incorrect logics before releasing 
real product.

NULL check doesn't mean the above things.

By NULL checking, the real product would have potential disasters which were 
not found in development process.



-Regards, Hermet-
-Original Message-
From: "Daniel Juyung Seo" 
To: "Enlightenment developer list"; 
Cc: ; 
Sent: 2012-09-06 (목) 19:25:16
Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib

Yes in dev mode, we can fix it early by crashing it.
But I don't want to allow this kind of window manager crash in a real product.

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:21 PM, ChunEon Park @naver.com> wrote:
> Thanks to u,
>  The problem was found out early.
>
>
> 
> -Regards, Hermet-
> -Original Message-
> From: "Daniel Juyung Seo"@gmail.com>
> To: "Enlightenment developer 
> list"@lists.sourceforge.net>;
> Cc: @lists.sourceforge.net>;
> Sent: 2012-09-06 (목) 19:15:48
> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>
> the problem is that. it was not a small application crash.
> my e17 is crashed.
> for users, this is bad :(
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Sep 6, 2012 at 7:13 PM, ChunEon Park @naver.com> wrote:
>> but we could found out the problem early.
>> 
>>
>> -Regards, Hermet-
>>
>> -Original Message-----
>> From: "Daniel Juyung Seo"@gmail.com>
>> To: @lists.sourceforge.net>;
>> Cc: @lists.sourceforge.net>;
>> Sent: 2012-09-06 (목) 19:08:39
>> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>>
>> Thanks. Great!
>> Now E17 works. Arggg NULL check!!!
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
>> @enlightenment.org> wrote:
>> > Log:
>> > edje: correct NULL check. Happy SeoZ :-)
>> >
>> >
>> > Author:   cedric
>> > Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
>> > New Revision: 76235
>> > Trac: http://trac.enlightenment.org/e/changeset/76235
>> >
>> > Modified:
>> >   trunk/edje/src/lib/edje_util.c
>> >
>> > Modified: trunk/edje/src/lib/edje_util.c
>> > ===
>> > --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 76234)
>> > +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 76235)
>> > @@ -5083,9 +5083,7 @@
>> >   rp);
>> >
>> > //If the map is enabled, uv should be updated when image size is 
>> > changed.
>> > -   if (rp->swallowed_object &&
>> > -   evas_object_type_get(rp->swallowed_object) &&
>> > -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>> > +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>> >   evas_object_event_callback_add(obj_swallow, 
>> > EVAS_CALLBACK_IMAGE_RESIZE,
>> >  
>> > _edje_object_part_swallow_image_resize_cb,
>> >  rp);
>> > @@ -5118,6 +5116,7 @@
>> >  void
>> >  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
>> >  {
>> > +   if (!rp->swallowed_object) return ;
>> > evas_object_smart_member_del(rp->swallowed_object);
>> > evas_object_event_callback_del_full(rp->swallowed_object,
>> > EVAS_CALLBACK_DEL,
>> >
>> >
>> > --
>> > 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-svn mailing list
>> > enlightenment-...@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today&#x

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Daniel Juyung Seo]

I am serious.
It was horrible experience as a user.

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:25 PM, Daniel Juyung Seo  wrote:
> Yes in dev mode, we can fix it early by crashing it.
> But I don't want to allow this kind of window manager crash in a real product.
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Sep 6, 2012 at 7:21 PM, ChunEon Park  wrote:
>> Thanks to u,
>>  The problem was found out early.
>>
>>
>> 
>> -Regards, Hermet-
>> -Original Message-
>> From: "Daniel Juyung Seo"
>> To: "Enlightenment developer 
>> list";
>> Cc: ;
>> Sent: 2012-09-06 (목) 19:15:48
>> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>>
>> the problem is that. it was not a small application crash.
>> my e17 is crashed.
>> for users, this is bad :(
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> On Thu, Sep 6, 2012 at 7:13 PM, ChunEon Park @naver.com> wrote:
>>> but we could found out the problem early.
>>> ------------------------
>>>
>>> -Regards, Hermet-
>>>
>>> -Original Message-
>>> From: "Daniel Juyung Seo"
>>> To: ;
>>> Cc: ;
>>> Sent: 2012-09-06 (목) 19:08:39
>>> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>>>
>>> Thanks. Great!
>>> Now E17 works. Arggg NULL check!!!
>>>
>>> Daniel Juyung Seo (SeoZ)
>>>
>>> On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
>>> @enlightenment.org> wrote:
>>> > Log:
>>> > edje: correct NULL check. Happy SeoZ :-)
>>> >
>>> >
>>> > Author:   cedric
>>> > Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
>>> > New Revision: 76235
>>> > Trac: http://trac.enlightenment.org/e/changeset/76235
>>> >
>>> > Modified:
>>> >   trunk/edje/src/lib/edje_util.c
>>> >
>>> > Modified: trunk/edje/src/lib/edje_util.c
>>> > ===
>>> > --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 
>>> > 76234)
>>> > +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 
>>> > 76235)
>>> > @@ -5083,9 +5083,7 @@
>>> >   rp);
>>> >
>>> > //If the map is enabled, uv should be updated when image size is 
>>> > changed.
>>> > -   if (rp->swallowed_object &&
>>> > -   evas_object_type_get(rp->swallowed_object) &&
>>> > -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>>> > +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>>> >   evas_object_event_callback_add(obj_swallow, 
>>> > EVAS_CALLBACK_IMAGE_RESIZE,
>>> >  
>>> > _edje_object_part_swallow_image_resize_cb,
>>> >  rp);
>>> > @@ -5118,6 +5116,7 @@
>>> >  void
>>> >  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
>>> >  {
>>> > +   if (!rp->swallowed_object) return ;
>>> > evas_object_smart_member_del(rp->swallowed_object);
>>> > evas_object_event_callback_del_full(rp->swallowed_object,
>>> > EVAS_CALLBACK_DEL,
>>> >
>>> >
>>> > --
>>> > 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-svn mailing list
>>> > enlightenment-...@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>>
>>> --
>>> 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. Dis

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Daniel Juyung Seo]

Yes in dev mode, we can fix it early by crashing it.
But I don't want to allow this kind of window manager crash in a real product.

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:21 PM, ChunEon Park  wrote:
> Thanks to u,
>  The problem was found out early.
>
>
> 
> -Regards, Hermet-
> -Original Message-
> From: "Daniel Juyung Seo"
> To: "Enlightenment developer list";
> Cc: ;
> Sent: 2012-09-06 (목) 19:15:48
> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>
> the problem is that. it was not a small application crash.
> my e17 is crashed.
> for users, this is bad :(
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Sep 6, 2012 at 7:13 PM, ChunEon Park @naver.com> wrote:
>> but we could found out the problem early.
>> 
>>
>> -Regards, Hermet-
>>
>> -----Original Message-----
>> From: "Daniel Juyung Seo"
>> To: ;
>> Cc: ;
>> Sent: 2012-09-06 (목) 19:08:39
>> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>>
>> Thanks. Great!
>> Now E17 works. Arggg NULL check!!!
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
>> @enlightenment.org> wrote:
>> > Log:
>> > edje: correct NULL check. Happy SeoZ :-)
>> >
>> >
>> > Author:   cedric
>> > Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
>> > New Revision: 76235
>> > Trac: http://trac.enlightenment.org/e/changeset/76235
>> >
>> > Modified:
>> >   trunk/edje/src/lib/edje_util.c
>> >
>> > Modified: trunk/edje/src/lib/edje_util.c
>> > ===
>> > --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 76234)
>> > +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 76235)
>> > @@ -5083,9 +5083,7 @@
>> >   rp);
>> >
>> > //If the map is enabled, uv should be updated when image size is 
>> > changed.
>> > -   if (rp->swallowed_object &&
>> > -   evas_object_type_get(rp->swallowed_object) &&
>> > -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>> > +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>> >   evas_object_event_callback_add(obj_swallow, 
>> > EVAS_CALLBACK_IMAGE_RESIZE,
>> >  
>> > _edje_object_part_swallow_image_resize_cb,
>> >  rp);
>> > @@ -5118,6 +5116,7 @@
>> >  void
>> >  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
>> >  {
>> > +   if (!rp->swallowed_object) return ;
>> > evas_object_smart_member_del(rp->swallowed_object);
>> > evas_object_event_callback_del_full(rp->swallowed_object,
>> > EVAS_CALLBACK_DEL,
>> >
>> >
>> > --
>> > 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-svn mailing list
>> > enlightenment-...@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>> --
>> 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
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the 

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[ChunEon Park]

Thanks to u,
 The problem was found out early.



-Regards, Hermet-
-Original Message-
From: "Daniel Juyung Seo" 
To: "Enlightenment developer list"; 
Cc: ; 
Sent: 2012-09-06 (목) 19:15:48
Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib

the problem is that. it was not a small application crash.
my e17 is crashed.
for users, this is bad :(

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:13 PM, ChunEon Park @naver.com> wrote:
> but we could found out the problem early.
> 
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Daniel Juyung Seo"
> To: ;
> Cc: ;
> Sent: 2012-09-06 (목) 19:08:39
> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>
> Thanks. Great!
> Now E17 works. Arggg NULL check!!!
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
> @enlightenment.org> wrote:
> > Log:
> > edje: correct NULL check. Happy SeoZ :-)
> >
> >
> > Author:   cedric
> > Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
> > New Revision: 76235
> > Trac: http://trac.enlightenment.org/e/changeset/76235
> >
> > Modified:
> >   trunk/edje/src/lib/edje_util.c
> >
> > Modified: trunk/edje/src/lib/edje_util.c
> > ===
> > --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 76234)
> > +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 76235)
> > @@ -5083,9 +5083,7 @@
> >   rp);
> >
> > //If the map is enabled, uv should be updated when image size is 
> > changed.
> > -   if (rp->swallowed_object &&
> > -   evas_object_type_get(rp->swallowed_object) &&
> > -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> > +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> >   evas_object_event_callback_add(obj_swallow, 
> > EVAS_CALLBACK_IMAGE_RESIZE,
> >  
> > _edje_object_part_swallow_image_resize_cb,
> >  rp);
> > @@ -5118,6 +5116,7 @@
> >  void
> >  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
> >  {
> > +   if (!rp->swallowed_object) return ;
> > evas_object_smart_member_del(rp->swallowed_object);
> > evas_object_event_callback_del_full(rp->swallowed_object,
> > EVAS_CALLBACK_DEL,
> >
> >
> > --
> > 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-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's securi

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Daniel Juyung Seo]

the problem is that. it was not a small application crash.
my e17 is crashed.
for users, this is bad :(

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:13 PM, ChunEon Park  wrote:
> but we could found out the problem early.
> 
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Daniel Juyung Seo"<seojuyu...@gmail.com>
> To: <enlightenment-devel@lists.sourceforge.net>;
> Cc: <enlightenment-...@lists.sourceforge.net>;
> Sent: 2012-09-06 (목) 19:08:39
> Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib
>
> Thanks. Great!
> Now E17 works. Arggg NULL check!!!
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
> <no-reply>@enlightenment.org> wrote:
> > Log:
> > edje: correct NULL check. Happy SeoZ :-)
> >
> >
> > Author:   cedric
> > Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
> > New Revision: 76235
> > Trac: http://trac.enlightenment.org/e/changeset/76235
> >
> > Modified:
> >   trunk/edje/src/lib/edje_util.c
> >
> > Modified: trunk/edje/src/lib/edje_util.c
> > ===
> > --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 
> 76234)
> > +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 
> 76235)
> > @@ -5083,9 +5083,7 @@
> >   rp);
> >
> > //If the map is enabled, uv should be updated when image size is 
> changed.
> > -   if (rp->swallowed_object &&
> > -   evas_object_type_get(rp->swallowed_object) &&
> > -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> > +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> >   evas_object_event_callback_add(obj_swallow, 
> EVAS_CALLBACK_IMAGE_RESIZE,
> >  
> _edje_object_part_swallow_image_resize_cb,
> >  rp);
> > @@ -5118,6 +5116,7 @@
> >  void
> >  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
> >  {
> > +   if (!rp->swallowed_object) return ;
> > evas_object_smart_member_del(rp->swallowed_object);
> > evas_object_event_callback_del_full(rp->swallowed_object,
> > EVAS_CALLBACK_DEL,
> >
> >
> > 
> --
> > 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-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[ChunEon Park]

but we could found out the problem early.


-Regards, Hermet-

-Original Message-
From: "Daniel Juyung Seo"<seojuyu...@gmail.com> 
To: <enlightenment-devel@lists.sourceforge.net>; 
Cc: <enlightenment-...@lists.sourceforge.net>; 
Sent: 2012-09-06 (목) 19:08:39
Subject: Re: [E-devel] E SVN: cedric trunk/edje/src/lib

Thanks. Great!
Now E17 works. Arggg NULL check!!!

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
<no-reply>@enlightenment.org> wrote:
> Log:
> edje: correct NULL check. Happy SeoZ :-)
>
>
> Author:   cedric
> Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
> New Revision: 76235
> Trac: http://trac.enlightenment.org/e/changeset/76235
>
> Modified:
>   trunk/edje/src/lib/edje_util.c
>
> Modified: trunk/edje/src/lib/edje_util.c
> ===
> --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 76234)
> +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 76235)
> @@ -5083,9 +5083,7 @@
>   rp);
>
> //If the map is enabled, uv should be updated when image size is 
changed.
> -   if (rp->swallowed_object &&
> -   evas_object_type_get(rp->swallowed_object) &&
> -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>   evas_object_event_callback_add(obj_swallow, 
EVAS_CALLBACK_IMAGE_RESIZE,
>  
_edje_object_part_swallow_image_resize_cb,
>  rp);
> @@ -5118,6 +5116,7 @@
>  void
>  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
>  {
> +   if (!rp->swallowed_object) return ;
> evas_object_smart_member_del(rp->swallowed_object);
> evas_object_event_callback_del_full(rp->swallowed_object,
> EVAS_CALLBACK_DEL,
>
>
> 
--
> 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-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Daniel Juyung Seo]

Thanks. Great!
Now E17 works. Arggg NULL check!!!

Daniel Juyung Seo (SeoZ)

On Thu, Sep 6, 2012 at 7:05 PM, Enlightenment SVN
 wrote:
> Log:
> edje: correct NULL check. Happy SeoZ :-)
>
>
> Author:   cedric
> Date: 2012-09-06 03:05:34 -0700 (Thu, 06 Sep 2012)
> New Revision: 76235
> Trac: http://trac.enlightenment.org/e/changeset/76235
>
> Modified:
>   trunk/edje/src/lib/edje_util.c
>
> Modified: trunk/edje/src/lib/edje_util.c
> ===
> --- trunk/edje/src/lib/edje_util.c  2012-09-06 10:01:44 UTC (rev 76234)
> +++ trunk/edje/src/lib/edje_util.c  2012-09-06 10:05:34 UTC (rev 76235)
> @@ -5083,9 +5083,7 @@
>   rp);
>
> //If the map is enabled, uv should be updated when image size is changed.
> -   if (rp->swallowed_object &&
> -   evas_object_type_get(rp->swallowed_object) &&
> -   !strcmp(evas_object_type_get(rp->swallowed_object), "image"))
> +   if (!strcmp(evas_object_type_get(rp->swallowed_object), "image"))
>   evas_object_event_callback_add(obj_swallow, EVAS_CALLBACK_IMAGE_RESIZE,
>  
> _edje_object_part_swallow_image_resize_cb,
>  rp);
> @@ -5118,6 +5116,7 @@
>  void
>  _edje_real_part_swallow_clear(Edje_Real_Part *rp)
>  {
> +   if (!rp->swallowed_object) return ;
> evas_object_smart_member_del(rp->swallowed_object);
> evas_object_event_callback_del_full(rp->swallowed_object,
> EVAS_CALLBACK_DEL,
>
>
> --
> 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-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[David Seikel]

On Wed, 30 Nov 2011 06:01:02 -0500 Michael Blumenkrantz
 wrote:

> On Wed, 30 Nov 2011 11:58:11 +0100
> Cedric BAIL  wrote:
> 
> > On Wed, Nov 30, 2011 at 11:18 AM, Michael Blumenkrantz
> >  wrote:
> > > On Wed, 30 Nov 2011 10:50:13 +0100
> > > Cedric BAIL  wrote:
> > >
> > >> On Wed, Nov 30, 2011 at 3:48 AM, Michael Blumenkrantz
> > >>  wrote:
> > >> > On Sun, 27 Nov 2011 15:55:38 -0800
> > >> > "Enlightenment SVN"  wrote:
> > >> >
> > >> >> Log:
> > >> >> edje: major cleanup of map calc in edje, now done inside
> > >> >> Edje_Calc_Param.
> > >> >>
> > >> >>   NOTE: This was necessary for solving issue with the new
> > >> >> CURRENT feature. I don't like this massive change, but there
> > >> >> is no way around. This patch is only the first step, I will
> > >> >> wait the full night before completly fixing the issue with
> > >> >> CURRENT.
> > >> >>
> > >> >>   WARNING: If this patch doesn't break svn, you must feel
> > >> >> lucky and go play money games. In all other case, please
> > >> >> report any issue to the developper mailing-list.
> > >> >>
> > >> >>
> > >> >> Author:       cedric
> > >> >> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> > >> >> New Revision: 65619
> > >> >> Trac:         http://trac.enlightenment.org/e/changeset/65619
> > >> >>
> > >> >> Modified:
> > >> >>   trunk/edje/src/lib/edje_calc.c
> > >> >> trunk/edje/src/lib/edje_private.h
> > >> >>
> > >> > this breaks compile without calc cache. please if you're going
> > >> > to break stuff, at least test compile with and without
> > >> > relevant options.
> > >>
> > >> Sorry it compile for me. Could you tell me the error message and
> > >> your compile option ?
> > > edje_calc.c: In function '_edje_part_recalc':
> > > edje_calc.c:2314: error: 'Edje_Real_Part' has no member named
> > > 'invalidate' edje_calc.c:2314: error: 'proxy_invalidate'
> > > undeclared (first use in this function) edje_calc.c:2314: error:
> > > (Each undeclared identifier is reported only once
> > > edje_calc.c:2314: error: for each function it appears in.)
> > 
> > Fixed in svn.
> > 
> > > --disable-calc-cache
> > 
> > I didn't remember we turned on by default the calc cache. That's
> > interesting.
> me neither. hooray for it being on though! :)

I guess this is the cache thingy you were telling me to turn on?  Yeah,
I already had it turned on.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Michael Blumenkrantz]

On Wed, 30 Nov 2011 11:58:11 +0100
Cedric BAIL  wrote:

> On Wed, Nov 30, 2011 at 11:18 AM, Michael Blumenkrantz
>  wrote:
> > On Wed, 30 Nov 2011 10:50:13 +0100
> > Cedric BAIL  wrote:
> >
> >> On Wed, Nov 30, 2011 at 3:48 AM, Michael Blumenkrantz
> >>  wrote:
> >> > On Sun, 27 Nov 2011 15:55:38 -0800
> >> > "Enlightenment SVN"  wrote:
> >> >
> >> >> Log:
> >> >> edje: major cleanup of map calc in edje, now done inside
> >> >> Edje_Calc_Param.
> >> >>
> >> >>   NOTE: This was necessary for solving issue with the new CURRENT
> >> >> feature. I don't like this massive change, but there is no way around.
> >> >> This patch is only the first step, I will wait the full night before
> >> >> completly fixing the issue with CURRENT.
> >> >>
> >> >>   WARNING: If this patch doesn't break svn, you must feel lucky and go
> >> >> play money games. In all other case, please report any issue to the
> >> >> developper mailing-list.
> >> >>
> >> >>
> >> >> Author:       cedric
> >> >> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> >> >> New Revision: 65619
> >> >> Trac:         http://trac.enlightenment.org/e/changeset/65619
> >> >>
> >> >> Modified:
> >> >>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h
> >> >>
> >> > this breaks compile without calc cache. please if you're going to break
> >> > stuff, at least test compile with and without relevant options.
> >>
> >> Sorry it compile for me. Could you tell me the error message and your
> >> compile option ?
> > edje_calc.c: In function '_edje_part_recalc':
> > edje_calc.c:2314: error: 'Edje_Real_Part' has no member named 'invalidate'
> > edje_calc.c:2314: error: 'proxy_invalidate' undeclared (first use in this
> > function) edje_calc.c:2314: error: (Each undeclared identifier is reported
> > only once edje_calc.c:2314: error: for each function it appears in.)
> 
> Fixed in svn.
> 
> > --disable-calc-cache
> 
> I didn't remember we turned on by default the calc cache. That's interesting.
me neither. hooray for it being on though! :)

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Cedric BAIL]

On Wed, Nov 30, 2011 at 11:18 AM, Michael Blumenkrantz
 wrote:
> On Wed, 30 Nov 2011 10:50:13 +0100
> Cedric BAIL  wrote:
>
>> On Wed, Nov 30, 2011 at 3:48 AM, Michael Blumenkrantz
>>  wrote:
>> > On Sun, 27 Nov 2011 15:55:38 -0800
>> > "Enlightenment SVN"  wrote:
>> >
>> >> Log:
>> >> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>> >>
>> >>   NOTE: This was necessary for solving issue with the new CURRENT feature.
>> >> I don't like this massive change, but there is no way around. This patch 
>> >> is
>> >>   only the first step, I will wait the full night before completly fixing
>> >>   the issue with CURRENT.
>> >>
>> >>   WARNING: If this patch doesn't break svn, you must feel lucky and go 
>> >> play
>> >>   money games. In all other case, please report any issue to the 
>> >> developper
>> >>   mailing-list.
>> >>
>> >>
>> >> Author:       cedric
>> >> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
>> >> New Revision: 65619
>> >> Trac:         http://trac.enlightenment.org/e/changeset/65619
>> >>
>> >> Modified:
>> >>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h
>> >>
>> > this breaks compile without calc cache. please if you're going to break
>> > stuff, at least test compile with and without relevant options.
>>
>> Sorry it compile for me. Could you tell me the error message and your
>> compile option ?
> edje_calc.c: In function '_edje_part_recalc':
> edje_calc.c:2314: error: 'Edje_Real_Part' has no member named 'invalidate'
> edje_calc.c:2314: error: 'proxy_invalidate' undeclared (first use in this
> function) edje_calc.c:2314: error: (Each undeclared identifier is reported 
> only
> once edje_calc.c:2314: error: for each function it appears in.)

Fixed in svn.

> --disable-calc-cache

I didn't remember we turned on by default the calc cache. That's interesting.
-- 
Cedric BAIL

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Michael Blumenkrantz]

On Wed, 30 Nov 2011 10:50:13 +0100
Cedric BAIL  wrote:

> On Wed, Nov 30, 2011 at 3:48 AM, Michael Blumenkrantz
>  wrote:
> > On Sun, 27 Nov 2011 15:55:38 -0800
> > "Enlightenment SVN"  wrote:
> >
> >> Log:
> >> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
> >>
> >>   NOTE: This was necessary for solving issue with the new CURRENT feature.
> >> I don't like this massive change, but there is no way around. This patch is
> >>   only the first step, I will wait the full night before completly fixing
> >>   the issue with CURRENT.
> >>
> >>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
> >>   money games. In all other case, please report any issue to the developper
> >>   mailing-list.
> >>
> >>
> >> Author:       cedric
> >> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> >> New Revision: 65619
> >> Trac:         http://trac.enlightenment.org/e/changeset/65619
> >>
> >> Modified:
> >>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h
> >>
> > this breaks compile without calc cache. please if you're going to break
> > stuff, at least test compile with and without relevant options.
> 
> Sorry it compile for me. Could you tell me the error message and your
> compile option ?
edje_calc.c: In function '_edje_part_recalc':
edje_calc.c:2314: error: 'Edje_Real_Part' has no member named 'invalidate'
edje_calc.c:2314: error: 'proxy_invalidate' undeclared (first use in this
function) edje_calc.c:2314: error: (Each undeclared identifier is reported only
once edje_calc.c:2314: error: for each function it appears in.)

--disable-calc-cache

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Cedric BAIL]

On Wed, Nov 30, 2011 at 3:48 AM, Michael Blumenkrantz
 wrote:
> On Sun, 27 Nov 2011 15:55:38 -0800
> "Enlightenment SVN"  wrote:
>
>> Log:
>> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>>
>>   NOTE: This was necessary for solving issue with the new CURRENT feature. I
>>   don't like this massive change, but there is no way around. This patch is
>>   only the first step, I will wait the full night before completly fixing
>>   the issue with CURRENT.
>>
>>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
>>   money games. In all other case, please report any issue to the developper
>>   mailing-list.
>>
>>
>> Author:       cedric
>> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
>> New Revision: 65619
>> Trac:         http://trac.enlightenment.org/e/changeset/65619
>>
>> Modified:
>>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h
>>
> this breaks compile without calc cache. please if you're going to break stuff,
> at least test compile with and without relevant options.

Sorry it compile for me. Could you tell me the error message and your
compile option ?
-- 
Cedric BAIL

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Michael Blumenkrantz]

On Sun, 27 Nov 2011 15:55:38 -0800
"Enlightenment SVN"  wrote:

> Log:
> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>   
>   NOTE: This was necessary for solving issue with the new CURRENT feature. I
>   don't like this massive change, but there is no way around. This patch is
>   only the first step, I will wait the full night before completly fixing
>   the issue with CURRENT.
>   
>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
>   money games. In all other case, please report any issue to the developper
>   mailing-list.
>   
> 
> Author:   cedric
> Date: 2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> New Revision: 65619
> Trac: http://trac.enlightenment.org/e/changeset/65619
> 
> Modified:
>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h 
> 
this breaks compile without calc cache. please if you're going to break stuff,
at least test compile with and without relevant options.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Cedric BAIL]

On Mon, Nov 28, 2011 at 6:20 AM, Carsten Haitzler  wrote:
> On Sun, 27 Nov 2011 15:55:38 -0800 "Enlightenment SVN"
>  said:
>
>> Log:
>> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>>
>>   NOTE: This was necessary for solving issue with the new CURRENT feature. I
>>   don't like this massive change, but there is no way around. This patch is
>>   only the first step, I will wait the full night before completly fixing
>>   the issue with CURRENT.
>>
>>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
>>   money games. In all other case, please report any issue to the developper
>>   mailing-list.
>>
>>
>> Author:       cedric
>> Date:         2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
>> New Revision: 65619
>> Trac:         http://trac.enlightenment.org/e/changeset/65619
>
> this broke cpufreq dials  broke map in edje... :(

Damn, I just saw it this morning ! I didn't notice that before, grumbl
:'( Looking at it !
-- 
Cedric BAIL

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[The Rasterman]

On Sun, 27 Nov 2011 15:55:38 -0800 "Enlightenment SVN"
 said:

> Log:
> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>   
>   NOTE: This was necessary for solving issue with the new CURRENT feature. I
>   don't like this massive change, but there is no way around. This patch is
>   only the first step, I will wait the full night before completly fixing
>   the issue with CURRENT.
>   
>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
>   money games. In all other case, please report any issue to the developper
>   mailing-list.
>   
> 
> Author:   cedric
> Date: 2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> New Revision: 65619
> Trac: http://trac.enlightenment.org/e/changeset/65619

this broke cpufreq dials  broke map in edje... :(


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Michael Blumenkrantz]

On Sun, 27 Nov 2011 15:55:38 -0800
"Enlightenment SVN"  wrote:

> Log:
> edje: major cleanup of map calc in edje, now done inside Edje_Calc_Param.
>   
>   NOTE: This was necessary for solving issue with the new CURRENT feature. I
>   don't like this massive change, but there is no way around. This patch is
>   only the first step, I will wait the full night before completly fixing
>   the issue with CURRENT.
>   
>   WARNING: If this patch doesn't break svn, you must feel lucky and go play
>   money games. In all other case, please report any issue to the developper
>   mailing-list.
>   
> 
> Author:   cedric
> Date: 2011-11-27 15:55:37 -0800 (Sun, 27 Nov 2011)
> New Revision: 65619
> Trac: http://trac.enlightenment.org/e/changeset/65619
> 
> Modified:
>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_private.h 
> 
oh good we haven't had any commits like this in a while. I was thinking that
you'd lost your touch

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[David Seikel]

On Sun, 20 Nov 2011 06:15:37 -0800 "Enlightenment SVN"
 wrote:

> Log:
> edje: remove warning when building without Ecore_IMF.
>   
> 
> Author:   cedric
> Date: 2011-11-20 06:15:37 -0800 (Sun, 20 Nov 2011)
> New Revision: 65440
> Trac: http://trac.enlightenment.org/e/changeset/65440
> 
> Modified:
>   trunk/edje/src/lib/edje_entry.c 
> 
> Modified: trunk/edje/src/lib/edje_entry.c
> ===
> --- trunk/edje/src/lib/edje_entry.c   2011-11-20 14:11:50 UTC
> (rev 65439) +++ trunk/edje/src/lib/edje_entry.c   2011-11-20
> 14:15:37 UTC (rev 65440) @@ -1508,9 +1508,9 @@
>  _edje_key_up_cb(void *data, Evas *e __UNUSED__, Evas_Object *obj
> __UNUSED__, void *event_info) {
> Edje *ed = data;
> -   Evas_Event_Key_Up *ev = event_info;
> Edje_Real_Part *rp = ed->focused_part;
> Entry *en;
> +
> if (!rp) return;
> en = rp->entry_data;
> if ((!en) || (rp->part->type != EDJE_PART_TYPE_TEXTBLOCK) ||
> @@ -1520,13 +1520,17 @@
>  #ifdef HAVE_ECORE_IMF
> if (en->imf_context)
>   {
> +Evas_Event_Key_Up *ev = event_info;
>  Ecore_IMF_Event_Key_Up ecore_ev;
> +
>  ecore_imf_evas_event_key_up_wrap(ev, &ecore_ev);
>  if (ecore_imf_context_filter_event(en->imf_context,
> ECORE_IMF_EVENT_KEY_UP,
> (Ecore_IMF_Event
> *)&ecore_ev)) return;
>   }
> +#else
> +   (void) event_info;
>  #endif
>  }
>  
> @@ -2057,9 +2061,9 @@
>  ecore_imf_context_input_mode_set(en->imf_context,
>   rp->part->entry_mode ==
> EDJE_ENTRY_EDIT_MODE_PASSWORD ? ECORE_IMF_INPUT_MODE_INVISIBLE :
> ECORE_IMF_INPUT_MODE_FULL); 
> +done:
>  #endif
>   }
> -done:
> en->cursor = (Evas_Textblock_Cursor
> *)evas_object_textblock_cursor_get(rp->object); }
>  

Think you just broke it here.

edje_entry.c: In function ‘_edje_entry_real_part_init’:
edje_entry.c:2064: error: label at end of compound statement


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

backport to 1.0 ?

On Sun, 14 Aug 2011, Enlightenment SVN wrote:

> Log:
> edje: fix cache and proxy.
>
>
> Author:   cedric
> Date: 2011-08-14 14:55:31 -0700 (Sun, 14 Aug 2011)
> New Revision: 62464
> Trac: http://trac.enlightenment.org/e/changeset/62464
>
> Modified:
>  trunk/edje/src/lib/edje_calc.c
>
> Modified: trunk/edje/src/lib/edje_calc.c
> ===
> --- trunk/edje/src/lib/edje_calc.c2011-08-14 21:47:17 UTC (rev 62463)
> +++ trunk/edje/src/lib/edje_calc.c2011-08-14 21:55:31 UTC (rev 62464)
> @@ -1948,6 +1948,7 @@
> _edje_part_recalc(Edje *ed, Edje_Real_Part *ep, int flags)
> {
> #ifdef EDJE_CALC_CACHE
> +   Eina_Bool proxy_invalidate = EINA_FALSE;
>int state1 = -1;
>int state2 = -1;
>int statec = -1;
> @@ -2101,6 +2102,24 @@
>   return;
>  }
>
> +   if (ep->part->type == EDJE_PART_TYPE_PROXY)
> + {
> +Edje_Real_Part *pp;
> +int part_id;
> +
> +if (pos >= 0.5)
> +  part_id = ((Edje_Part_Description_Proxy*) 
> ep->param2->description)->proxy.id;
> +else
> +  part_id = ((Edje_Part_Description_Proxy*) chosen_desc)->proxy.id;
> +pp = ed->table_parts[part_id % ed->table_parts_size];
> +#ifdef EDJE_CALC_CACHE
> +if (pp->invalidate)
> +  proxy_invalidate = EINA_TRUE;
> +#endif
> +
> +if (!pp->calculated) _edje_part_recalc(ed, ep, flags);
> + }
> +
> #ifndef EDJE_CALC_CACHE
>p1 = &lp1;
> #else
> @@ -2114,6 +2133,7 @@
>   ep->invalidate ||
>   state1 >= ep->param1.state ||
>   statec >= ep->param1.state ||
> +proxy_invalidate ||
>   ((ep->part->type == EDJE_PART_TYPE_TEXT || ep->part->type == 
> EDJE_PART_TYPE_TEXTBLOCK) && ed->text_part_change))
> #endif
> {
> @@ -2143,6 +2163,7 @@
>   ep->invalidate ||
>   state2 >= ep->param2->state ||
>   statec >= ep->param2->state ||
> +proxy_invalidate ||
>   ((ep->part->type == EDJE_PART_TYPE_TEXT || ep->part->type == 
> EDJE_PART_TYPE_TEXTBLOCK) && ed->text_part_change))
> #endif
> {
>
>
> --
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy
> to use, easy to manage, easy to install, easy to extend.
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[The Rasterman]

On Wed, 22 Jun 2011 07:51:53 -0700 "Enlightenment SVN"
 said:

so... what about colorclasses? they probably have the same problems as the last
2 textclass commit fixes. :)

> Log:
> edje: fix huge memory leak.
>   
> 
> Author:   cedric
> Date: 2011-06-22 07:51:53 -0700 (Wed, 22 Jun 2011)
> New Revision: 60593
> Trac: http://trac.enlightenment.org/e/changeset/60593
> 
> Modified:
>   trunk/edje/src/lib/edje_main.c trunk/edje/src/lib/edje_private.h
> trunk/edje/src/lib/edje_util.c 
> 
> Modified: trunk/edje/src/lib/edje_main.c
> ===
> --- trunk/edje/src/lib/edje_main.c2011-06-22 14:04:09 UTC (rev 60592)
> +++ trunk/edje/src/lib/edje_main.c2011-06-22 14:51:53 UTC (rev 60593)
> @@ -150,7 +150,7 @@
>  _text_class_member_free(const Eina_Hash *hash __UNUSED__,
>   const void *key,
>   void *data,
> - void *fdata)
> + void *fdata __UNUSED__)
>  {
> _edje_text_class_member_direct_del(key, data);
> return EINA_TRUE;
> 
> Modified: trunk/edje/src/lib/edje_private.h
> ===
> --- trunk/edje/src/lib/edje_private.h 2011-06-22 14:04:09 UTC (rev
> 60592) +++ trunk/edje/src/lib/edje_private.h  2011-06-22 14:51:53 UTC
> (rev 60593) @@ -1545,7 +1545,7 @@
>  Edje_Text_Class  *_edje_text_class_find(Edje *ed, const char *text_class);
>  void  _edje_text_class_member_add(Edje *ed, const char
> *text_class); void  _edje_text_class_member_del(Edje *ed, const
> char *text_class); -void  _edje_text_class_member_direct_del
> (const char *text_class, Eina_List *lookup); +void
> _edje_text_class_member_direct_del(const char *text_class, void *lookup);
> void  _edje_text_class_members_free(void); void
> _edje_text_class_hash_free(void); 
> 
> Modified: trunk/edje/src/lib/edje_util.c
> ===
> --- trunk/edje/src/lib/edje_util.c2011-06-22 14:04:09 UTC (rev 60592)
> +++ trunk/edje/src/lib/edje_util.c2011-06-22 14:51:53 UTC (rev 60593)
> @@ -32,6 +32,14 @@
> Eina_List *list;
>  };
>  
> +typedef struct _Edje_List_Refcount Edje_List_Refcount;
> +struct _Edje_List_Refcount
> +{
> +   EINA_REFCOUNT;
> +
> +   Eina_List *lookup;
> +};
> +
>  static Eina_Bool _edje_color_class_list_foreach(const Eina_Hash *hash, const
> void *key, void *data, void *fdata); static Eina_Bool
> _edje_text_class_list_foreach(const Eina_Hash *hash, const void *key, void
> *data, void *fdata); static void _edje_object_image_preload_cb(void *data,
> Evas *e, Evas_Object *obj, void *event_info); @@ -3711,34 +3719,46 @@ 
>  void
>  _edje_text_class_member_direct_del(const char *text_class,
> -   Eina_List *lookup)
> +   void *l)
>  {
> +   Edje_List_Refcount *lookup = l;
> Eina_List *members;
>  
> members = eina_hash_find(_edje_text_class_member_hash, text_class);
> -   members = eina_list_remove_list(members, lookup);
> +   members = eina_list_remove_list(members, lookup->lookup);
> eina_hash_set(_edje_text_class_member_hash, text_class, members);
> +   free(lookup);
>  }
>  
>  void
>  _edje_text_class_member_add(Edje *ed, const char *text_class)
>  {
> +   Edje_List_Refcount *lookup;
> Eina_List *members;
>  
> if ((!ed) || (!text_class)) return;
>  
> +   lookup = eina_hash_find(ed->members, text_class);
> +   if (lookup)
> + {
> +EINA_REFCOUNT_REF(lookup);
> +return;
> + }
> +
> +   lookup = malloc(sizeof (Edje_List_Refcount));
> +   if (!lookup) return ;
> +   EINA_REFCOUNT_INIT(lookup);
> +
> /* Get members list */
> members = eina_hash_find(_edje_text_class_member_hash, text_class);
>  
> /* Update the member list */
> -   members = eina_list_prepend(members, ed);
> -   if (eina_list_count(members) > 5)
> -  printf("ERROR. CEDRIC BROKE ME! I NOW LEAK TEXTCLASSES\n");
> +   lookup->lookup = members = eina_list_prepend(members, ed);
>  
> /* Don't loose track of members list */
> if (!ed->members)
>   ed->members = eina_hash_string_small_new(NULL);
> -   eina_hash_set(ed->members, text_class, members);
> +   eina_hash_add(ed->members, text_class, lookup);
>  
> /* Reset the member list to the right pointer */
> if (!_edje_text_class_member_hash)
> @@ -3749,21 +3769,24 @@
>  void
>  _edje_text_class_member_del(Edje *ed, const char *text_class)
>  {
> +   Edje_List_Refcount *lookup;
> Eina_List *members;
> -   Eina_List *lookup;
>  
> if ((!ed) || (!text_class)) return;
> members = eina_hash_find(_edje_text_class_member_hash, text_class);
> if (!members) return;
>  
> lookup = eina_hash_find(ed->members, text_class);
> -
> if (!lookup) return ;
>  
> -   eina_hash_del(ed->members, text_class, lookup);
> -   members = eina_list_remo

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Atton Jonathan]

This patch broke everything.

If the signal is o*bj[id]:signal*.

Elementary is waiting *[id]:signal* and this patch provides *signal *which
is not enough. Elm need the* id.*
I do not know what cedric was trying to do and he is at holidays for 2
weeks.

I think we should revert it.

2010/11/30 Enlightenment SVN 

> Log:
>* edje: the most simple and usefull case of alias convertion
>wasn't implemented at all. Should be working now, please test
>all your code that relly on "part1:part2[index]:sig" behaviour.
>
>
> Author:   cedric
> Date: 2010-11-30 05:09:03 -0800 (Tue, 30 Nov 2010)
> New Revision: 55086
> Trac: http://trac.enlightenment.org/e/changeset/55086
>
> Modified:
>  trunk/edje/src/lib/edje_program.c
>
> Modified: trunk/edje/src/lib/edje_program.c
> ===
> --- trunk/edje/src/lib/edje_program.c   2010-11-30 12:59:08 UTC (rev 55085)
> +++ trunk/edje/src/lib/edje_program.c   2010-11-30 13:09:03 UTC (rev 55086)
> @@ -1001,83 +1001,61 @@
>
>if (ed->delete_me) return;
>
> -   sep = strchr(sig, EDJE_PART_PATH_SEPARATOR);
> +   sep = strrchr(sig, EDJE_PART_PATH_SEPARATOR);
>
>/* If we are not sending the signal to a part of the child, the
> * signal if for ourself
> */
>if (sep)
>  {
> -char *idx, *newsig;
> +Edje_Real_Part *rp;
> +char *newsig;
> size_t length;
> char *part;
> -unsigned int i;
>
> -/* the signal contains a colon, split the signal into
> "part:signal",
> - * and deliver it to "part" (if there is a GROUP or EXTERNAL part
> named "part")
> +/* the signal contains a colon, split the signal into
> "parts:signal",
> + * use _edje_real_part_recursive_get_helper to find the real part.
>  */
> length = strlen(sig) + 1;
> part = alloca(length);
> memcpy(part, sig, length);
>
> -/* The part contain a [index], retrieve it */
> -idx = strchr(sig, EDJE_PART_PATH_SEPARATOR_INDEXL);
> -if (!idx || sep < idx) newsig = part + (sep - sig);
> -else newsig = part + (idx - sig);
> +newsig = part + (sep - sig);
>
> *newsig = '\0';
> newsig++;
>
> -for (i = 0; i < ed->table_parts_size; i++)
> +rp = _edje_real_part_recursive_get(ed, part);
> +if (rp && rp->part)
>   {
> - Edje_Real_Part *rp = ed->table_parts[i];
> - if rp->part->type == EDJE_PART_TYPE_GROUP
> -|| rp->part->type == EDJE_PART_TYPE_EXTERNAL)
> -   && (rp->swallowed_object))
> -  || rp->part->type == EDJE_PART_TYPE_BOX ||
> rp->part->type == EDJE_PART_TYPE_TABLE) &&
> - (rp->part) && (rp->part->name) &&
> - (strcmp(rp->part->name, part) == 0))
> + switch (rp->part->type)
>{
> -  if (rp->part->type == EDJE_PART_TYPE_GROUP)
> -{
> -   Edje *ed2 = _edje_fetch(rp->swallowed_object);
> -   if (ed2) _edje_emit(ed2, newsig, src);
> -   return; /* stop processing.
> -* XXX maybe let signal be processed
> anyway?
> -* XXX in this case, just comment this line
> -*/
> -}
> -  else if (rp->part->type == EDJE_PART_TYPE_EXTERNAL)
> -{
> -   _edje_external_signal_emit(rp->swallowed_object,
> newsig, src);
> -   return;
> -}
> -  else if (rp->part->type == EDJE_PART_TYPE_BOX
> -   || rp->part->type == EDJE_PART_TYPE_TABLE)
> -{
> -   const char *partid;
> -   Evas_Object *child;
> -   Edje *ed2 = NULL;
> +case EDJE_PART_TYPE_GROUP:
> +  {
> + Edje *ed2;
>
> -   idx = strchr(newsig,
> EDJE_PART_PATH_SEPARATOR_INDEXR);
> + if (!rp->swallowed_object) break ;
>
> -   if (!idx) return ;
> -   if (idx[1] != ':') return ;
> -   if (!rp->object) return;
> + ed2 = _edje_fetch(rp->swallowed_object);
> + if (ed2) _edje_emit(ed2, newsig, src);
> + return; /* stop processing.
> +  * XXX maybe let signal be processed anyway?
> +  * XXX in this case, just comment this line
> +  */
> +  }
> +case EDJE_PART_TYPE_EXTERNAL:
> +  {
> + if (!rp->swallowed_object) break ;
>
> -   partid = newsig;
> -   newsig =

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Gustavo Sverzut Barbieri]

On Fri, Dec 3, 2010 at 4:21 PM, Enlightenment SVN
 wrote:
> Log:
>        * edje: SPANK ! SPANK ! SPANK !
>
>        fprintf should always specify a format.
>
>
> Author:       cedric
> Date:         2010-12-03 10:21:56 -0800 (Fri, 03 Dec 2010)
> New Revision: 55213
> Trac:         http://trac.enlightenment.org/e/changeset/55213
>
> Modified:
>  trunk/edje/src/lib/edje_edit.c
>
> Modified: trunk/edje/src/lib/edje_edit.c
> ===
> --- trunk/edje/src/lib/edje_edit.c      2010-12-03 18:12:19 UTC (rev 55212)
> +++ trunk/edje/src/lib/edje_edit.c      2010-12-03 18:21:56 UTC (rev 55213)
> @@ -6357,7 +6357,7 @@
>              success = EINA_FALSE;
>           }
>         else
> -          fprintf(f, eed->embryo_processed);
> +          fprintf(f, "%s", eed->embryo_processed);
>      }
>
>    it = eina_hash_iterator_data_new(eed->program_scripts);
> @@ -6384,7 +6384,7 @@
>              continue;
>           }
>         fprintf(f, "public _p%i(sig[], src[]) {\n", ps->id);
> -        fprintf(f, ps->processed);
> +        fprintf(f, "%s", ps->processed);

although GCC is smart and it shouldn't matter much, you should
actually call fputs() :-) (gcc should do it automatically)

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Brett Nash]

On Thu, 3 Jun 2010 07:26:43 +0200 (CEST)
Vincent Torri  wrote:

> 
> 
> On Thu, 3 Jun 2010, Carsten Haitzler (The Rasterman) wrote:
> 
> > On Wed, 2 Jun 2010 20:24:28 +0200 (CEST) Vincent Torri
> >  said:
> >
> > all other callback adds use const void *data - and that's correct
> > as it means the add doesnt do anything to what data points to
> > (doesn't modify) but the callback itself that is passed this
> > pointer gets void * as the callback can modiy what it points to.
> 
> but it breaks the 'const' chain. In that case, there is no interest
> of using any const pointers (for me).I like the C++ way of using
> const: if you pass a const pointer, at some point, you are sure that
> is it never modified later.

Unfortunately C doesn't have the correct way to describe what we are
after (this call won't modify the data, but you can do what you want to
it, since it's yours).  If we really really wanted to preserve
appropriate const attributes we'd need two versions of each function:
one for const data, and one for non-const, and even then it would fail
to indicate EFL doesn't modify the data.

Note the C standard library has _exactly_ the same problem.  [I'm sure
either the c89 or c99 rational document described this, but I can't
find it anywhere - maybe a defect notice]

Examples:
char *strstr(const char *, const char *);

Which returns you a non const version of the const paramater, so C
(and C++) programmers should be aware of the problem.  And since the
users of the library then DON'T need to cast their modifiable data or
the unmodifiable data (as long as their types are correct), it's all
fine.

Regards,
nash

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

On Thu, 3 Jun 2010, Carsten Haitzler (The Rasterman) wrote:

> On Wed, 2 Jun 2010 20:24:28 +0200 (CEST) Vincent Torri 
> said:
>
> all other callback adds use const void *data - and that's correct as it means
> the add doesnt do anything to what data points to (doesn't modify) but the
> callback itself that is passed this pointer gets void * as the callback can
> modiy what it points to.

but it breaks the 'const' chain. In that case, there is no interest of 
using any const pointers (for me).I like the C++ way of using const: if 
you pass a const pointer, at some point, you are sure that is it never 
modified later.

Vincent

>
>>
>>
>> On Tue, 1 Jun 2010, Enlightenment SVN wrote:
>>
>>> Log:
>>> * edje: fix constness warning.
>>>
>>> Author:   cedric
>>> Date: 2010-06-01 07:35:19 -0700 (Tue, 01 Jun 2010)
>>> New Revision: 49372
>>>
>>> Modified:
>>>  trunk/edje/src/lib/edje_util.c
>>>
>>> Modified: trunk/edje/src/lib/edje_util.c
>>> ===
>>> --- trunk/edje/src/lib/edje_util.c  2010-06-01 14:26:09 UTC (rev
>>> 49371) +++ trunk/edje/src/lib/edje_util.c   2010-06-01 14:35:19 UTC
>>> (rev 49372) @@ -2136,7 +2136,7 @@
>>>cb = calloc(1, sizeof(Edje_Text_Insert_Filter_Callback));
>>>cb->part = eina_stringshare_add(part);
>>>cb->func = func;
>>> -   cb->data = data;
>>> +   cb->data = (void*) data;
>>
>> wouldn't it be better to change
>> edje_object_text_insert_filter_callback_add() so that data is just a void
>> *
>>
>> Indeed, if data is const void *, you alert the user that data will *not*
>> be modified. But the callback says that it can modify it.
>>
>> Imho, what is currently done is not good
>>
>> Also, it's (void *) and not (void*) :p
>>
>> Vincent
>>
>>>ed->text_insert_filter_callbacks =
>>>  eina_list_append(ed->text_insert_filter_callbacks, cb);
>>> }
>>> @@ -2152,7 +2152,7 @@
>>>if ((!ed) || (!part)) return;
>>>EINA_LIST_FOREACH(ed->text_insert_filter_callbacks, l, cb)
>>>  {
>>> -if ((!strcmp(cb->part, part)) && (cb->func == func))
>>> +if ((!strcmp(cb->part, part)) && (cb->func == func) && (cb->data
>>> == data)) {
>>>  ed->text_insert_filter_callbacks =
>>>eina_list_remove_list(ed->text_insert_filter_callbacks, l);
>>>
>>>
>>> --
>>>
>>> ___
>>> enlightenment-svn mailing list
>>> enlightenment-...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>>
>>>
>>
>> --
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[The Rasterman]

On Wed, 2 Jun 2010 20:24:28 +0200 (CEST) Vincent Torri 
said:

all other callback adds use const void *data - and that's correct as it means
the add doesnt do anything to what data points to (doesn't modify) but the
callback itself that is passed this pointer gets void * as the callback can
modiy what it points to.

> 
> 
> On Tue, 1 Jun 2010, Enlightenment SVN wrote:
> 
> > Log:
> > * edje: fix constness warning.
> >
> > Author:   cedric
> > Date: 2010-06-01 07:35:19 -0700 (Tue, 01 Jun 2010)
> > New Revision: 49372
> >
> > Modified:
> >  trunk/edje/src/lib/edje_util.c
> >
> > Modified: trunk/edje/src/lib/edje_util.c
> > ===
> > --- trunk/edje/src/lib/edje_util.c  2010-06-01 14:26:09 UTC (rev
> > 49371) +++ trunk/edje/src/lib/edje_util.c   2010-06-01 14:35:19 UTC
> > (rev 49372) @@ -2136,7 +2136,7 @@
> >cb = calloc(1, sizeof(Edje_Text_Insert_Filter_Callback));
> >cb->part = eina_stringshare_add(part);
> >cb->func = func;
> > -   cb->data = data;
> > +   cb->data = (void*) data;
> 
> wouldn't it be better to change 
> edje_object_text_insert_filter_callback_add() so that data is just a void 
> *
> 
> Indeed, if data is const void *, you alert the user that data will *not* 
> be modified. But the callback says that it can modify it.
> 
> Imho, what is currently done is not good
> 
> Also, it's (void *) and not (void*) :p
> 
> Vincent
> 
> >ed->text_insert_filter_callbacks =
> >  eina_list_append(ed->text_insert_filter_callbacks, cb);
> > }
> > @@ -2152,7 +2152,7 @@
> >if ((!ed) || (!part)) return;
> >EINA_LIST_FOREACH(ed->text_insert_filter_callbacks, l, cb)
> >  {
> > -if ((!strcmp(cb->part, part)) && (cb->func == func))
> > +if ((!strcmp(cb->part, part)) && (cb->func == func) && (cb->data
> > == data)) {
> >  ed->text_insert_filter_callbacks =
> >eina_list_remove_list(ed->text_insert_filter_callbacks, l);
> >
> >
> > --
> >
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> >
> 
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

On Tue, 1 Jun 2010, Enlightenment SVN wrote:

> Log:
>   * edje: fix constness warning.
>
> Author:   cedric
> Date: 2010-06-01 07:35:19 -0700 (Tue, 01 Jun 2010)
> New Revision: 49372
>
> Modified:
>  trunk/edje/src/lib/edje_util.c
>
> Modified: trunk/edje/src/lib/edje_util.c
> ===
> --- trunk/edje/src/lib/edje_util.c2010-06-01 14:26:09 UTC (rev 49371)
> +++ trunk/edje/src/lib/edje_util.c2010-06-01 14:35:19 UTC (rev 49372)
> @@ -2136,7 +2136,7 @@
>cb = calloc(1, sizeof(Edje_Text_Insert_Filter_Callback));
>cb->part = eina_stringshare_add(part);
>cb->func = func;
> -   cb->data = data;
> +   cb->data = (void*) data;

wouldn't it be better to change 
edje_object_text_insert_filter_callback_add() so that data is just a void 
*

Indeed, if data is const void *, you alert the user that data will *not* 
be modified. But the callback says that it can modify it.

Imho, what is currently done is not good

Also, it's (void *) and not (void*) :p

Vincent

>ed->text_insert_filter_callbacks =
>  eina_list_append(ed->text_insert_filter_callbacks, cb);
> }
> @@ -2152,7 +2152,7 @@
>if ((!ed) || (!part)) return;
>EINA_LIST_FOREACH(ed->text_insert_filter_callbacks, l, cb)
>  {
> -if ((!strcmp(cb->part, part)) && (cb->func == func))
> +if ((!strcmp(cb->part, part)) && (cb->func == func) && (cb->data == 
> data))
>   {
>  ed->text_insert_filter_callbacks =
>eina_list_remove_list(ed->text_insert_filter_callbacks, l);
>
>
> --
>
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Cedric BAIL]

On Wed, Oct 7, 2009 at 1:45 PM, Vincent Torri  wrote:
> On Wed, 7 Oct 2009, Enlightenment SVN wrote:
>> Log:
>>       * edje: Another round of llvm warning removal.
>>
>> Author:       cedric
>> Date:         2009-10-07 04:36:23 -0700 (Wed, 07 Oct 2009)
>> New Revision: 42932
>>
>> Modified:
>>  trunk/edje/src/lib/edje_edit.c trunk/edje/src/lib/edje_util.c
>>
>> Modified: trunk/edje/src/lib/edje_edit.c
>> ===
>> --- trunk/edje/src/lib/edje_edit.c    2009-10-07 11:27:15 UTC (rev 42931)
>> +++ trunk/edje/src/lib/edje_edit.c    2009-10-07 11:36:23 UTC (rev 42932)
>> @@ -5378,7 +5378,7 @@
>>    strcpy(tmpn, "/tmp/edje_edit.edc-tmp-XX");
>>    if (!(fd = mkstemp(tmpn))) return NULL;
>>    printf("*** tmp file: %s\n", tmpn);
>> -   if (!(f = fopen(tmpn, "w"))) return NULL;
>> +   if (!(f = fdopen(fd, "w"))) return NULL;
>
> can you please use "wb", for compatibility with Windows ? (i can't do that
> right now)

In svn, if you have time please take a look at this file, I saw other
comment regarding code not working on windows.

-- 
Cedric BAIL

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

On Wed, 7 Oct 2009, Enlightenment SVN wrote:

> Log:
>   * edje: Another round of llvm warning removal.
>
> Author:   cedric
> Date: 2009-10-07 04:36:23 -0700 (Wed, 07 Oct 2009)
> New Revision: 42932
>
> Modified:
>  trunk/edje/src/lib/edje_edit.c trunk/edje/src/lib/edje_util.c
>
> Modified: trunk/edje/src/lib/edje_edit.c
> ===
> --- trunk/edje/src/lib/edje_edit.c2009-10-07 11:27:15 UTC (rev 42931)
> +++ trunk/edje/src/lib/edje_edit.c2009-10-07 11:36:23 UTC (rev 42932)
> @@ -5378,7 +5378,7 @@
>strcpy(tmpn, "/tmp/edje_edit.edc-tmp-XX");
>if (!(fd = mkstemp(tmpn))) return NULL;
>printf("*** tmp file: %s\n", tmpn);
> -   if (!(f = fopen(tmpn, "w"))) return NULL;
> +   if (!(f = fdopen(fd, "w"))) return NULL;

can you please use "wb", for compatibility with Windows ? (i can't do that 
right now)

Vincent

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Gustavo Sverzut Barbieri]

On Sat, Aug 15, 2009 at 7:20 AM, Carsten Haitzler wrote:
> On Mon, 10 Aug 2009 12:21:11 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
>> SVN wrote:
>> > Log:
>> >        * edje: Reduce sizeof (Edje_Calc_Params).
>> >
>> >        Note: It doesn't really impact edje memory foot print yet. But in
>> >        the plan to do a computation cache inside edje, this structure
>> >        will be used a lot (I am planning to do this feature at some point,
>> >        but no ETA yet, and be reassured it will be optionnal so we can
>> >        choose between CPU load or memory load).
>> >
>> >        Note: As I was looking for similar area of improvements,
>> >        Edje_Part_Description could really use an union to reduce it's size,
>> >        but as we load this structure directly from an Eet file, we need
>> >        union in Eet first. And this should be part of a comming Edje file
>> >        format break.
>>
>> Better than union is to have the single part in one structure and
>> specific bits in their own structure. Depending on how we do the Eet +
>> union support, we may think on how to do it to cover this case as
>> well.
>>
>> I'd say instead of allocate memory and fill it, one could give a
>> "type" value to user callback and then it would receive the correct
>> Eet_Data_Descriptor for that subtype. So union would return the data
>> descriptor with the same struct size for all types, while dynamic
>> would check (switch/case) which one to use, and return the fields
>> properly.
>>
>> This is likely to reduce memory consumption a lot because we often
>> have LOTS of rectangle that have almost no field, while we have very
>> few TEXT/TEXTBLOCK/GRADIENT that consume most memory.
>>
>> BTW, something that could improve memory there is using mempool.
>
> even mempool will fragment. it isnt necessarily a silver bullet. not 
> allocating
> is better than anything else :) i am wondering if simple N structs with 
> casting
> is best (and a common header in all for common members for all types).

Yes, and this is really the best solution BUT with current fscking
huge code it's very hard to do. As I said to cedric, go and do a
refactor to isolate parts dealing with common bits or specific (text,
textblock) in separate functions, than errors will be harder to
happen.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[The Rasterman]

On Mon, 10 Aug 2009 12:21:11 -0300 Gustavo Sverzut Barbieri
 said:

> On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
> SVN wrote:
> > Log:
> >        * edje: Reduce sizeof (Edje_Calc_Params).
> >
> >        Note: It doesn't really impact edje memory foot print yet. But in
> >        the plan to do a computation cache inside edje, this structure
> >        will be used a lot (I am planning to do this feature at some point,
> >        but no ETA yet, and be reassured it will be optionnal so we can
> >        choose between CPU load or memory load).
> >
> >        Note: As I was looking for similar area of improvements,
> >        Edje_Part_Description could really use an union to reduce it's size,
> >        but as we load this structure directly from an Eet file, we need
> >        union in Eet first. And this should be part of a comming Edje file
> >        format break.
> 
> Better than union is to have the single part in one structure and
> specific bits in their own structure. Depending on how we do the Eet +
> union support, we may think on how to do it to cover this case as
> well.
> 
> I'd say instead of allocate memory and fill it, one could give a
> "type" value to user callback and then it would receive the correct
> Eet_Data_Descriptor for that subtype. So union would return the data
> descriptor with the same struct size for all types, while dynamic
> would check (switch/case) which one to use, and return the fields
> properly.
> 
> This is likely to reduce memory consumption a lot because we often
> have LOTS of rectangle that have almost no field, while we have very
> few TEXT/TEXTBLOCK/GRADIENT that consume most memory.
> 
> BTW, something that could improve memory there is using mempool.

even mempool will fragment. it isnt necessarily a silver bullet. not allocating
is better than anything else :) i am wondering if simple N structs with casting
is best (and a common header in all for common members for all types).

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[The Rasterman]

On Mon, 10 Aug 2009 18:39:23 +0200 Cedric BAIL  said:

> On Mon, Aug 10, 2009 at 5:21 PM, Gustavo Sverzut
> Barbieri wrote:
> > On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
> > SVN wrote:
> >> Log:
> >>        * edje: Reduce sizeof (Edje_Calc_Params).
> >>
> >>        Note: It doesn't really impact edje memory foot print yet. But in
> >>        the plan to do a computation cache inside edje, this structure
> >>        will be used a lot (I am planning to do this feature at some point,
> >>        but no ETA yet, and be reassured it will be optionnal so we can
> >>        choose between CPU load or memory load).
> >>
> >>        Note: As I was looking for similar area of improvements,
> >>        Edje_Part_Description could really use an union to reduce it's size,
> >>        but as we load this structure directly from an Eet file, we need
> >>        union in Eet first. And this should be part of a comming Edje file
> >>        format break.
> >
> > Better than union is to have the single part in one structure and
> > specific bits in their own structure. Depending on how we do the Eet +
> > union support, we may think on how to do it to cover this case as
> > well.
> >
> > I'd say instead of allocate memory and fill it, one could give a
> > "type" value to user callback and then it would receive the correct
> > Eet_Data_Descriptor for that subtype. So union would return the data
> > descriptor with the same struct size for all types, while dynamic
> > would check (switch/case) which one to use, and return the fields
> > properly.
> >
> > This is likely to reduce memory consumption a lot because we often
> > have LOTS of rectangle that have almost no field, while we have very
> > few TEXT/TEXTBLOCK/GRADIENT that consume most memory.
> 
> Hum, that's another possibility, this is almost like implementing some
> object "inheritence" support in eet. This could be much more efficient
> than using union, but only if type can't change, or you could be
> forced to reallocate another structure. But this seems more usefull
> than union for Edje. Will put this somewhere in the TODO :-)
> 
> > BTW, something that could improve memory there is using mempool.
> 
> I don't really see how, what do you want to put inside this mempool
> (one per type of edje object ?) ?

but Edje_Calc_Params is runtime - not in the .edj file :) no need to worry
about eet here.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Christopher Michael]

Enlightenment SVN wrote:
> Log:
>   * edje_calc: Major cleanup.
>   - Edje_Real_Part use less memory.
>   - Edje_Real_Part and Edje_Real_Part_State now use a mempool.
>   - When both param1 and param2 are the same, only recalc param1.
>   - Don't compute Edje_Real_Part more than one time per 
> edje_recalc_do.
>
To this last statement...I say A MEan !! :))


>   
> Author:   cedric
> Date: 2009-08-14 10:19:42 -0700 (Fri, 14 Aug 2009)
> New Revision: 41771
> 
> Modified:
>   trunk/edje/src/lib/edje_calc.c trunk/edje/src/lib/edje_edit.c 
> trunk/edje/src/lib/edje_embryo.c trunk/edje/src/lib/edje_load.c 
> trunk/edje/src/lib/edje_main.c trunk/edje/src/lib/edje_private.h 
> 
> Modified: trunk/edje/src/lib/edje_calc.c
> ===
> --- trunk/edje/src/lib/edje_calc.c2009-08-14 17:17:01 UTC (rev 41770)
> +++ trunk/edje/src/lib/edje_calc.c2009-08-14 17:19:42 UTC (rev 41771)
> @@ -65,7 +65,7 @@
>   return ep->default_desc;
>  
> if (!strcmp(name, "custom"))
> - return rp->custom.description;
> + return rp->custom ? rp->custom->description : NULL;
>  
> if (!strcmp(name, "default"))
>   {
> @@ -93,15 +93,33 @@
>  void
>  _edje_part_description_apply(Edje *ed, Edje_Real_Part *ep, const char *d1, 
> double v1, const char *d2, double v2)
>  {
> +   Edje_Part_Description *epd1;
> +   Edje_Part_Description *epd2;
> +
> if (!d1) d1 = "default";
> if (!d2) d2 = "default";
>  
> -   ep->param1.description = _edje_part_description_find(ed, ep, d1, v1);
> -   if (!ep->param1.description)
> - ep->param1.description = ep->part->default_desc; /* never NULL */
> +   epd1 = _edje_part_description_find(ed, ep, d1, v1);
> +   if (!epd1)
> + epd1 = ep->part->default_desc; /* never NULL */
>  
> -   ep->param2.description = _edje_part_description_find(ed, ep, d2, v2);
> +   epd2 = _edje_part_description_find(ed, ep, d2, v2);
>  
> +   if (epd2 != NULL && epd1 != epd2)
> + {
> + if (!ep->param2)
> +   ep->param2 = eina_mempool_malloc(_edje_real_part_state_mp, sizeof 
> (Edje_Real_Part_State));
> + }
> +   else
> + if (ep->param2)
> +   {
> +   eina_mempool_free(_edje_real_part_state_mp, ep->param2);
> +   ep->param2 = NULL;
> +   }
> +
> +   ep->param1.description = epd1;
> +   ep->chosen_description = epd1;
> +
> ep->param1.rel1_to_x = ep->param1.rel1_to_y = NULL;
> ep->param1.rel2_to_x = ep->param1.rel2_to_y = NULL;
>  
> @@ -114,26 +132,29 @@
> if (ep->param1.description->rel2.id_y >= 0)
>   ep->param1.rel2_to_y = 
> ed->table_parts[ep->param1.description->rel2.id_y % ed->table_parts_size];
>  
> -   ep->param2.rel1_to_x = ep->param2.rel1_to_y = NULL;
> -   ep->param2.rel2_to_x = ep->param2.rel2_to_y = NULL;
> +   if (ep->param2)
> + {
> + ep->param2->description = epd2;
>  
> -   if (ep->param2.description)
> - {
> - if (ep->param2.description->rel1.id_x >= 0)
> -   ep->param2.rel1_to_x = 
> ed->table_parts[ep->param2.description->rel1.id_x % ed->table_parts_size];
> - if (ep->param2.description->rel1.id_y >= 0)
> -   ep->param2.rel1_to_y = 
> ed->table_parts[ep->param2.description->rel1.id_y % ed->table_parts_size];
> - if (ep->param2.description->rel2.id_x >= 0)
> -   ep->param2.rel2_to_x = 
> ed->table_parts[ep->param2.description->rel2.id_x % ed->table_parts_size];
> - if (ep->param2.description->rel2.id_y >= 0)
> -   ep->param2.rel2_to_y = 
> ed->table_parts[ep->param2.description->rel2.id_y % ed->table_parts_size];
> + ep->param2->rel1_to_x = ep->param2->rel1_to_y = NULL;
> + ep->param2->rel2_to_x = ep->param2->rel2_to_y = NULL;
> +
> + if (ep->param2->description)
> +   {
> +  if (ep->param2->description->rel1.id_x >= 0)
> +ep->param2->rel1_to_x = 
> ed->table_parts[ep->param2->description->rel1.id_x % ed->table_parts_size];
> +  if (ep->param2->description->rel1.id_y >= 0)
> +ep->param2->rel1_to_y = 
> ed->table_parts[ep->param2->description->rel1.id_y % ed->table_parts_size];
> +  if (ep->param2->description->rel2.id_x >= 0)
> +ep->param2->rel2_to_x = 
> ed->table_parts[ep->param2->description->rel2.id_x % ed->table_parts_size];
> +  if (ep->param2->description->rel2.id_y >= 0)
> +ep->param2->rel2_to_y = 
> ed->table_parts[ep->param2->description->rel2.id_y % ed->table_parts_size];
> +   }
> +
> + if (ep->description_pos != 0.0)
> +   ep->chosen_description = epd2;
>   }
>  
> -   if (ep->description_pos == 0.0)
> - ep->chosen_description = ep->param1.description;
> -   else
> - ep->chosen_description = ep->param2.description;
> -
> ed->dirty = 1;
>  #ifdef EDJE_CALC_CACHE
> ep->invalidate = 1;
> @@ -1444,23 +1465,27 @@
> else
>   {
>   image_count = 2;
> - if (ep->param2.description)
> -   image_count += 
> eina_lis

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

On Thu, 13 Aug 2009, t...@hiddenrock.com wrote:

> On Thu, Aug 13, 2009 at 07:10:06PM +0200, Vincent Torri wrote:
>>
>>
>>> Modified: trunk/edje/src/lib/edje_private.h
>>> ===
>>> --- trunk/edje/src/lib/edje_private.h   2009-08-13 15:42:30 UTC (rev 
>>> 41743)
>>> +++ trunk/edje/src/lib/edje_private.h   2009-08-13 16:13:49 UTC (rev 
>>> 41744)
>>> @@ -740,7 +740,7 @@
>>>   int   angle; // 4
>>>   int   spread; // 4
>>>} fill;
>>> -   Edje_Color color, color2, color3; // 12
>>> +   Edje_Color color; // 4
>>>union {
>>>   struct {
>>>  int   l, r, t, b; // 16
>>> @@ -749,12 +749,13 @@
>>>  Edje_Alignment align; /* text alignment within bounds */ // 16
>>>  double elipsis; // 8
>>>  intsize; // 4
>>> -  } text; // 28
>>> +Edje_Color color2, color3; // 8
>>> +  } text; // 36
>>>   struct {
>>>  int id; // 4
>>>  char   *type; // 4
>>>   } gradient; // 8
>>> -   } type; // 28
>>> +   } type; // 36
>>>unsigned charvisible : 1;
>>>unsigned charsmooth : 1; // 4
>>> }; // 116
>>
>> note that on 64 bits computers, the size is bigger. Maybe one can put also
>> the size for that arch
>
> Or use the types from stdint.h: eg, uint8_t, uint16_t, uint32_t, etc.  Which
> are not only more consistent, but also self-documenting.

the difference is for pointers.

Vincent

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[tam]

On Thu, Aug 13, 2009 at 07:10:06PM +0200, Vincent Torri wrote:
> 
> 
> > Modified: trunk/edje/src/lib/edje_private.h
> > ===
> > --- trunk/edje/src/lib/edje_private.h   2009-08-13 15:42:30 UTC (rev 
> > 41743)
> > +++ trunk/edje/src/lib/edje_private.h   2009-08-13 16:13:49 UTC (rev 
> > 41744)
> > @@ -740,7 +740,7 @@
> >   int   angle; // 4
> >   int   spread; // 4
> >} fill;
> > -   Edje_Color color, color2, color3; // 12
> > +   Edje_Color color; // 4
> >union {
> >   struct {
> >  int   l, r, t, b; // 16
> > @@ -749,12 +749,13 @@
> >  Edje_Alignment align; /* text alignment within bounds */ // 16
> >  double elipsis; // 8
> >  intsize; // 4
> > -  } text; // 28
> > +Edje_Color color2, color3; // 8
> > +  } text; // 36
> >   struct {
> >  int id; // 4
> >  char   *type; // 4
> >   } gradient; // 8
> > -   } type; // 28
> > +   } type; // 36
> >unsigned charvisible : 1;
> >unsigned charsmooth : 1; // 4
> > }; // 116
> 
> note that on 64 bits computers, the size is bigger. Maybe one can put also 
> the size for that arch

Or use the types from stdint.h: eg, uint8_t, uint16_t, uint32_t, etc.  Which
are not only more consistent, but also self-documenting.

pete


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Vincent Torri]

> Modified: trunk/edje/src/lib/edje_private.h
> ===
> --- trunk/edje/src/lib/edje_private.h 2009-08-13 15:42:30 UTC (rev 41743)
> +++ trunk/edje/src/lib/edje_private.h 2009-08-13 16:13:49 UTC (rev 41744)
> @@ -740,7 +740,7 @@
>   int   angle; // 4
>   int   spread; // 4
>} fill;
> -   Edje_Color color, color2, color3; // 12
> +   Edje_Color color; // 4
>union {
>   struct {
>int   l, r, t, b; // 16
> @@ -749,12 +749,13 @@
>Edje_Alignment align; /* text alignment within bounds */ // 16
>double elipsis; // 8
>intsize; // 4
> -  } text; // 28
> +  Edje_Color color2, color3; // 8
> +  } text; // 36
>   struct {
>int id; // 4
>char   *type; // 4
>   } gradient; // 8
> -   } type; // 28
> +   } type; // 36
>unsigned charvisible : 1;
>unsigned charsmooth : 1; // 4
> }; // 116

note that on 64 bits computers, the size is bigger. Maybe one can put also 
the size for that arch

Vincent

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Gustavo Sverzut Barbieri]

On Mon, Aug 10, 2009 at 1:39 PM, Cedric BAIL wrote:
> On Mon, Aug 10, 2009 at 5:21 PM, Gustavo Sverzut
> Barbieri wrote:
>> On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
>> SVN wrote:
>>> Log:
>>>        * edje: Reduce sizeof (Edje_Calc_Params).
>>>
>>>        Note: It doesn't really impact edje memory foot print yet. But in
>>>        the plan to do a computation cache inside edje, this structure
>>>        will be used a lot (I am planning to do this feature at some point,
>>>        but no ETA yet, and be reassured it will be optionnal so we can
>>>        choose between CPU load or memory load).
>>>
>>>        Note: As I was looking for similar area of improvements,
>>>        Edje_Part_Description could really use an union to reduce it's size,
>>>        but as we load this structure directly from an Eet file, we need
>>>        union in Eet first. And this should be part of a comming Edje file
>>>        format break.
>>
>> Better than union is to have the single part in one structure and
>> specific bits in their own structure. Depending on how we do the Eet +
>> union support, we may think on how to do it to cover this case as
>> well.
>>
>> I'd say instead of allocate memory and fill it, one could give a
>> "type" value to user callback and then it would receive the correct
>> Eet_Data_Descriptor for that subtype. So union would return the data
>> descriptor with the same struct size for all types, while dynamic
>> would check (switch/case) which one to use, and return the fields
>> properly.
>>
>> This is likely to reduce memory consumption a lot because we often
>> have LOTS of rectangle that have almost no field, while we have very
>> few TEXT/TEXTBLOCK/GRADIENT that consume most memory.
>
> Hum, that's another possibility, this is almost like implementing some
> object "inheritence" support in eet. This could be much more efficient
> than using union, but only if type can't change, or you could be
> forced to reallocate another structure. But this seems more usefull
> than union for Edje. Will put this somewhere in the TODO :-)
>
>> BTW, something that could improve memory there is using mempool.
>
> I don't really see how, what do you want to put inside this mempool
> (one per type of edje object ?) ?

Edje_Part_Description is fixed size, would match perfectly fixed size
mempool allocators.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Cedric BAIL]

On Mon, Aug 10, 2009 at 5:21 PM, Gustavo Sverzut
Barbieri wrote:
> On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
> SVN wrote:
>> Log:
>>        * edje: Reduce sizeof (Edje_Calc_Params).
>>
>>        Note: It doesn't really impact edje memory foot print yet. But in
>>        the plan to do a computation cache inside edje, this structure
>>        will be used a lot (I am planning to do this feature at some point,
>>        but no ETA yet, and be reassured it will be optionnal so we can
>>        choose between CPU load or memory load).
>>
>>        Note: As I was looking for similar area of improvements,
>>        Edje_Part_Description could really use an union to reduce it's size,
>>        but as we load this structure directly from an Eet file, we need
>>        union in Eet first. And this should be part of a comming Edje file
>>        format break.
>
> Better than union is to have the single part in one structure and
> specific bits in their own structure. Depending on how we do the Eet +
> union support, we may think on how to do it to cover this case as
> well.
>
> I'd say instead of allocate memory and fill it, one could give a
> "type" value to user callback and then it would receive the correct
> Eet_Data_Descriptor for that subtype. So union would return the data
> descriptor with the same struct size for all types, while dynamic
> would check (switch/case) which one to use, and return the fields
> properly.
>
> This is likely to reduce memory consumption a lot because we often
> have LOTS of rectangle that have almost no field, while we have very
> few TEXT/TEXTBLOCK/GRADIENT that consume most memory.

Hum, that's another possibility, this is almost like implementing some
object "inheritence" support in eet. This could be much more efficient
than using union, but only if type can't change, or you could be
forced to reallocate another structure. But this seems more usefull
than union for Edje. Will put this somewhere in the TODO :-)

> BTW, something that could improve memory there is using mempool.

I don't really see how, what do you want to put inside this mempool
(one per type of edje object ?) ?

-- 
Cedric BAIL

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[Gustavo Sverzut Barbieri]

On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment
SVN wrote:
> Log:
>        * edje: Reduce sizeof (Edje_Calc_Params).
>
>        Note: It doesn't really impact edje memory foot print yet. But in
>        the plan to do a computation cache inside edje, this structure
>        will be used a lot (I am planning to do this feature at some point,
>        but no ETA yet, and be reassured it will be optionnal so we can
>        choose between CPU load or memory load).
>
>        Note: As I was looking for similar area of improvements,
>        Edje_Part_Description could really use an union to reduce it's size,
>        but as we load this structure directly from an Eet file, we need
>        union in Eet first. And this should be part of a comming Edje file
>        format break.

Better than union is to have the single part in one structure and
specific bits in their own structure. Depending on how we do the Eet +
union support, we may think on how to do it to cover this case as
well.

I'd say instead of allocate memory and fill it, one could give a
"type" value to user callback and then it would receive the correct
Eet_Data_Descriptor for that subtype. So union would return the data
descriptor with the same struct size for all types, while dynamic
would check (switch/case) which one to use, and return the fields
properly.

This is likely to reduce memory consumption a lot because we often
have LOTS of rectangle that have almost no field, while we have very
few TEXT/TEXTBLOCK/GRADIENT that consume most memory.

BTW, something that could improve memory there is using mempool.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel