Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib

[Vincent Torri]

NEWS ? ChangeLog ?

Vincent

On Tue, Jan 10, 2012 at 12:13 AM, Enlightenment SVN
 wrote:
> Log:
> Add eina_array_count(), deprecate eina_array_count_get().
>
>  This makes the API more uniform.
>
>
>
> Author:       barbieri
> Date:         2012-01-09 15:13:06 -0800 (Mon, 09 Jan 2012)
> New Revision: 67001
> Trac:         http://trac.enlightenment.org/e/changeset/67001
>
> Modified:
>  trunk/eina/src/include/eina_array.h 
> trunk/eina/src/include/eina_inline_array.x trunk/eina/src/lib/eina_array.c
>
> Modified: trunk/eina/src/include/eina_array.h
> ===
> --- trunk/eina/src/include/eina_array.h 2012-01-09 18:21:54 UTC (rev 67000)
> +++ trunk/eina/src/include/eina_array.h 2012-01-09 23:13:06 UTC (rev 67001)
> @@ -351,7 +351,8 @@
>  static inline void      eina_array_data_set(const Eina_Array *array,
>                                             unsigned int      idx,
>                                             const void       *data) 
> EINA_ARG_NONNULL(1);
> -static inline unsigned int eina_array_count_get(const Eina_Array *array) 
> EINA_ARG_NONNULL(1);
> +static inline unsigned int eina_array_count_get(const Eina_Array *array) 
> EINA_ARG_NONNULL(1) EINA_WARN_UNUSED_RESULT EINA_DEPRECATED;
> +static inline unsigned int eina_array_count(const Eina_Array *array) 
> EINA_ARG_NONNULL(1) EINA_WARN_UNUSED_RESULT;
>
>  /**
>  * @brief Returned a new iterator associated to an array.
> @@ -429,7 +430,7 @@
>  */
>  #define EINA_ARRAY_ITER_NEXT(array, index, item, iterator)                  \
>   for (index = 0, iterator = (array)->data;                                 \
> -       (index < eina_array_count_get(array)) && ((item = *((iterator)++))); \
> +       (index < eina_array_count(array)) && ((item = *((iterator)++)));     \
>                                                   ++(index))
>
>  #include "eina_inline_array.x"
>
> Modified: trunk/eina/src/include/eina_inline_array.x
> ===
> --- trunk/eina/src/include/eina_inline_array.x  2012-01-09 18:21:54 UTC (rev 
> 67000)
> +++ trunk/eina/src/include/eina_inline_array.x  2012-01-09 23:13:06 UTC (rev 
> 67001)
> @@ -128,6 +128,8 @@
>  * This function returns the number of elements in @p array. For
>  * performance reasons, there is no check of @p array. If it is
>  * @c NULL or invalid, the program may crash.
> + *
> + * @deprecated use eina_array_count()
>  */
>  static inline unsigned int
>  eina_array_count_get(const Eina_Array *array)
> @@ -135,6 +137,22 @@
>    return array->count;
>  }
>
> +/**
> + * @brief Return the number of elements in an array.
> + *
> + * @param array The array.
> + * @return The number of elements.
> + *
> + * This function returns the number of elements in @p array. For
> + * performance reasons, there is no check of @p array. If it is
> + * @c NULL or invalid, the program may crash.
> + */
> +static inline unsigned int
> +eina_array_count(const Eina_Array *array)
> +{
> +   return array->count;
> +}
> +
>  static inline Eina_Bool
>  eina_array_foreach(Eina_Array *array, Eina_Each_Cb cb, void *fdata)
>  {
>
> Modified: trunk/eina/src/lib/eina_array.c
> ===
> --- trunk/eina/src/lib/eina_array.c     2012-01-09 18:21:54 UTC (rev 67000)
> +++ trunk/eina/src/lib/eina_array.c     2012-01-09 23:13:06 UTC (rev 67001)
> @@ -119,7 +119,7 @@
>  {
>    EINA_MAGIC_CHECK_ARRAY_ITERATOR(it, EINA_FALSE);
>
> -   if (!(it->index < eina_array_count_get(it->array)))
> +   if (!(it->index < eina_array_count(it->array)))
>       return EINA_FALSE;
>
>    if (data)
> @@ -150,7 +150,7 @@
>  {
>    EINA_MAGIC_CHECK_ARRAY_ACCESSOR(it, EINA_FALSE);
>
> -   if (!(idx < eina_array_count_get(it->array)))
> +   if (!(idx < eina_array_count(it->array)))
>       return EINA_FALSE;
>
>    if (data)
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@list

Re: [E-devel] [Patch][Notify] Remove Unnecessary Code

[Jaehwan Kim]

in svn. Thanks :-)

2012년 1월 10일 화요일에 cnook님이 작성:

> Dear All, Hello~
>
> I have attached a patch for removing unnecessary code in the elm_notify.
> There is no swallow area for the parent In the notify.edc also.
> Even if the removed line is necessary, then it will cause an improper
> result.
> So it should be removed definitely and absolutely!
> Please review this and give any feedbacks. Thank you.
>
>
> Sincerely,
> Shinwoo Kim.
>
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [patch] elm_store - fix eina_lock ptr handling

[Hyoyoung Chang]

Dear all,

When i run 'store' menu in elementary_test, i met some segfault.
it's due to inappropriate eina_lock ptr handling.

Thanks
Index: elementary/src/lib/elm_store.c
===
--- elementary/src/lib/elm_store.c  (리비전 67007)
+++ elementary/src/lib/elm_store.c  (작업 사본)
@@ -47,7 +47,7 @@
Ecore_Job*eval_job;
const Elm_Store_Item_Mapping *mapping;
void *data;
-   Eina_Lock*lock;
+   Eina_Lock lock;
Eina_Bool live : 1;
Eina_Bool was_live : 1;
Eina_Bool realized : 1;
@@ -82,24 +82,24 @@
  st->realized = eina_list_remove_list(st->realized, st->realized);
  sti->realized = EINA_FALSE;
   }
-eina_lock_take(sti->lock);
+eina_lock_take(&sti->lock);
 if (!sti->fetched)
   {
- eina_lock_release(sti->lock);
+ eina_lock_release(&sti->lock);
  if (sti->fetch_th)
{
   ecore_thread_cancel(sti->fetch_th);
   sti->fetch_th = NULL;
}
- eina_lock_take(sti->lock);
+ eina_lock_take(&sti->lock);
   }
 sti->fetched = EINA_FALSE;
-eina_lock_release(sti->lock);
+eina_lock_release(&sti->lock);
 if (st->cb.unfetch.func)
   st->cb.unfetch.func(st->cb.unfetch.data, sti);
-eina_lock_take(sti->lock);
+eina_lock_take(&sti->lock);
 sti->data = NULL;
-eina_lock_release(sti->lock);
+eina_lock_release(&sti->lock);
  }
 }
 
@@ -130,7 +130,7 @@
st->cb.unfetch.func(st->cb.unfetch.data, sti);
  sti->data = NULL;
   }
-eina_lock_free(sti->lock);
+eina_lock_free(&sti->lock);
st->items = NULL;
 free(sti);
  }
@@ -145,21 +145,21 @@
 _store_filesystem_fetch_do(void *data, Ecore_Thread *th __UNUSED__)
 {
Elm_Store_Item *sti = data;
-   eina_lock_take(sti->lock);
+   eina_lock_take(&sti->lock);
if (sti->data)
  {
-eina_lock_release(sti->lock);
+eina_lock_release(&sti->lock);
 return;
  }
if (!sti->fetched)
  {
-eina_lock_release(sti->lock);
+eina_lock_release(&sti->lock);
 if (sti->store->cb.fetch.func)
   sti->store->cb.fetch.func(sti->store->cb.fetch.data, sti);
-eina_lock_take(sti->lock);
+eina_lock_take(&sti->lock);
 sti->fetched = EINA_TRUE;
  }
-   eina_lock_release(sti->lock);
+   eina_lock_release(&sti->lock);
 }
 // 
    * End of separate thread function. *
@@ -169,9 +169,9 @@
 _store_filesystem_fetch_end(void *data, Ecore_Thread *th)
 {
Elm_Store_Item *sti = data;
-   eina_lock_take(sti->lock);
+   eina_lock_take(&sti->lock);
if (sti->data) elm_genlist_item_update(sti->item);
-   eina_lock_release(sti->lock);
+   eina_lock_release(&sti->lock);
if (th == sti->fetch_th) sti->fetch_th = NULL;
 }
 
@@ -180,10 +180,10 @@
 _store_filesystem_fetch_cancel(void *data, Ecore_Thread *th)
 {
Elm_Store_Item *sti = data;
-   eina_lock_take(sti->lock);
+   eina_lock_take(&sti->lock);
if (th == sti->fetch_th) sti->fetch_th = NULL;
if (sti->data) elm_genlist_item_update(sti->item);
-   eina_lock_release(sti->lock);
+   eina_lock_release(&sti->lock);
 }
 
 static void
@@ -266,7 +266,7 @@
 {
Elm_Store_Item *sti = data;
const char *s = "";
-   eina_lock_take(sti->lock);
+   eina_lock_take(&sti->lock);
if (sti->data)
  {
 const Elm_Store_Item_Mapping *m = _store_item_mapping_find(sti, part);
@@ -286,7 +286,7 @@
}
   }
  }
-   eina_lock_release(sti->lock);
+   eina_lock_release(&sti->lock);
return s ? strdup(s) : NULL;
 }
 
@@ -294,7 +294,7 @@
 _store_item_content_get(void *data, Evas_Object *obj, const char *part)
 {
Elm_Store_Item *sti = data;
-   eina_lock_take(sti->lock);
+   eina_lock_take(&sti->lock);
if (sti->data)
  {
 const Elm_Store_Item_Mapping *m = _store_item_mapping_find(sti, part);
@@ -340,11 +340,11 @@
 default:
break;
}
- eina_lock_release(sti->lock);
+ eina_lock_release(&sti->lock);
  return ic;
   }
  }
-   eina_lock_release(sti->lock);
+   eina_lock_release(&sti->lock);
return NULL;
 }
 
@@ -442,7 +442,7 @@
 
sti = calloc(1, sizeof(Elm_Store_Item_Filesystem));
if (!sti) goto done;
-   eina_lock_new(sti->base.lock);
+   eina_lock_new(&sti->base.lock);
EINA_MAGIC_SET(&(sti->base), ELM_STORE_ITEM_MAGIC);
sti->base.store = st;
sti->base.data = info->base.data;
@@ -553,7 +553,7 @@
st->cb.unfetch.func(st->cb.unfetch.da

Re: [E-devel] [patch] elm_store - fix eina_lock ptr handling

[Hyoyoung Chang]

It's another patch file that describes a method to get a store example files.
If it's ok, plz commit it.
Thanks

On Tue, Jan 10, 2012 at 8:15 PM, Hyoyoung Chang  wrote:
> Dear all,
>
> When i run 'store' menu in elementary_test, i met some segfault.
> it's due to inappropriate eina_lock ptr handling.
>
> Thanks
Index: elementary/src/bin/test_store.c
===
--- elementary/src/bin/test_store.c (리비전 67014)
+++ elementary/src/bin/test_store.c (작업 사본)
@@ -1,3 +1,10 @@
+/* NOTE : Before testing elm_store,
+  email data files should exist in your local storage.
+  And you can just get example files in enlightenment website.
+  Use wget to obtain it. It almost 50 Megabytes.
+  http://www.enlightenment.org/~raster/store.tar.gz
+ */
+
 #include 
 
 #ifdef HAVE_CONFIG_H
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [patch] elc_multibuttonentry - checking focus before elm_widget_show_region_set

[Hyoyoung Chang]

Dear All

In elc_multibuttonentry, there're some elm_widget_show_region_set callings.
However it's not checking whether it got focused or not,
sometimes it's bugging users when the user's trying to move scroller.
So I changed to check focused.

Thanks
Index: elementary/src/lib/elc_multibuttonentry.c
===
--- elementary/src/lib/elc_multibuttonentry.c   (리비전 67014)
+++ elementary/src/lib/elc_multibuttonentry.c   (작업 사본)
@@ -175,6 +175,7 @@
if (elm_widget_focus_get(obj))
  {
 wd->focused = EINA_TRUE;
+if (wd->entry) elm_entry_cursor_end_set(wd->entry);
 evas_object_smart_callback_call(obj, "focused", NULL);
  }
else
@@ -1071,7 +1072,9 @@
evas_object_geometry_get(wd->entry, &en_x, &en_y, &en_w, &en_h);
evas_object_geometry_get(wd->box, &bx_x, &bx_y, NULL, NULL);
 
-   elm_widget_show_region_set(wd->box, en_x - bx_x, en_y - bx_y, en_w, en_h, 
EINA_TRUE);
+   if (wd->focused)
+ elm_widget_show_region_set(wd->box, en_x - bx_x, en_y - bx_y, en_w,
+en_h, EINA_TRUE);
 }
 
 static void
@@ -1105,7 +1108,6 @@
 if (!wd->entry) return;
 elm_entry_single_line_set(wd->entry, EINA_TRUE);
 elm_object_text_set(wd->entry, "");
-elm_entry_cursor_end_set(wd->entry);
 evas_object_size_hint_min_set(wd->entry, MIN_W_ENTRY, 0);
 evas_object_size_hint_weight_set(wd->entry, EVAS_HINT_EXPAND, 
EVAS_HINT_EXPAND);
 evas_object_size_hint_align_set(wd->entry, EVAS_HINT_FILL, 
EVAS_HINT_FILL);
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Sachiel]

2012/1/10 Daniel Juyung Seo :
> On Fri, Jan 6, 2012 at 11:34 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  wrote:
>>> Dear all
>>>
>>> This patch introduces four new apis about elm_gen{list, grid} item
>>> class managements.
>>> itc_add function makes a new item_class for the given widget.
>>> And itc_del function remove the item_class from the widget.
>>>
>>> Most of elm_gen{list, grid} users declare itc(item_class) as a global 
>>> variable.
>>> Because itc should be lived at elm_gen{list,grid} item's life cycle.
>>> It's inconvenient for users. Even some users pass itc.
>>>
>>> itc_add makes a new itc. if exact one exists in the given widget, it
>>> return the previous made itc.
>>> itc_del remove a itc if its reference count reaches at zero.
>>>
>>> Thanks.
>>>
>>>
>>> EAPI Elm_Genlist_Item_Class *
>>> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Genlist_Item_Text_Get_Cb text_cb,
>>>                    Elm_Genlist_Item_Content_Get_Cb content_cb,
>>>                    Elm_Genlist_Item_State_Get_Cb state_cb,
>>>                    Elm_Genlist_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
>>> EAPI Elm_Gengrid_Item_Class *
>>> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
>>>                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
>>>                    Elm_Gengrid_Item_State_Get_Cb state_cb,
>>>                    Elm_Gengrid_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>
>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>
>>
>> And really, majority of developers should NEVER use this, the global
>> static-const is the correct way to go, making sure memory is live,
>> unchanged, no mallocs, etc.
>
> Thanks for your reply. This patch has an assumption that application
> can alloc itc memory dynamically.
> If itc-dynamic-allocation is not recommended, do you have to use
> global variable for itc?
> For a huge app that uses many c sources, we can't force them to use
> global static :(
>

You are making a function to return a pre-made class for others to use?
Keep the class static to the function, return a pointer to it.

> Daniel Juyung Seo (SeoZ)
>
>>
>> Who may use this is bindings, like Python, JavaScript and that's it.
>> They have better ways to manage it.
>>
>> --
>> Gustavo Sverzut Barbieri
>> http://profusion.mobi embedded systems
>> --
>> MSN: barbi...@gmail.com
>> Skype: gsbarbieri
>> Mobile: +55 (19) 9225-2202
>>
>> --
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib

[Gustavo Sverzut Barbieri]

On Tue, Jan 10, 2012 at 6:58 AM, Vincent Torri  wrote:
> NEWS ? ChangeLog ?

don't think it's worth. When we remove the deprecated we add it.

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

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Gustavo Sverzut Barbieri]

On Tue, Jan 10, 2012 at 11:03 AM, Iván Briano (Sachiel)
 wrote:
> 2012/1/10 Daniel Juyung Seo :
>> On Fri, Jan 6, 2012 at 11:34 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  wrote:
 Dear all

 This patch introduces four new apis about elm_gen{list, grid} item
 class managements.
 itc_add function makes a new item_class for the given widget.
 And itc_del function remove the item_class from the widget.

 Most of elm_gen{list, grid} users declare itc(item_class) as a global 
 variable.
 Because itc should be lived at elm_gen{list,grid} item's life cycle.
 It's inconvenient for users. Even some users pass itc.

 itc_add makes a new itc. if exact one exists in the given widget, it
 return the previous made itc.
 itc_del remove a itc if its reference count reaches at zero.

 Thanks.


 EAPI Elm_Genlist_Item_Class *
 elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
                    Elm_Genlist_Item_Text_Get_Cb text_cb,
                    Elm_Genlist_Item_Content_Get_Cb content_cb,
                    Elm_Genlist_Item_State_Get_Cb state_cb,
                    Elm_Genlist_Item_Del_Cb del_cb);
 EAPI void
 elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
 EAPI Elm_Gengrid_Item_Class *
 elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
                    Elm_Gengrid_Item_State_Get_Cb state_cb,
                    Elm_Gengrid_Item_Del_Cb del_cb);
 EAPI void
 elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>>
>>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>>
>>>
>>> And really, majority of developers should NEVER use this, the global
>>> static-const is the correct way to go, making sure memory is live,
>>> unchanged, no mallocs, etc.
>>
>> Thanks for your reply. This patch has an assumption that application
>> can alloc itc memory dynamically.
>> If itc-dynamic-allocation is not recommended, do you have to use
>> global variable for itc?
>> For a huge app that uses many c sources, we can't force them to use
>> global static :(
>>
>
> You are making a function to return a pre-made class for others to use?
> Keep the class static to the function, return a pointer to it.

exactly, it just need to be static, not global. It is also recommended
to be "const", but it is not mandatory.

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

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib

[Cedric BAIL]

On Tue, Jan 10, 2012 at 2:19 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Jan 10, 2012 at 6:58 AM, Vincent Torri  
> wrote:
>> NEWS ? ChangeLog ?
>
> don't think it's worth. When we remove the deprecated we add it.

I disagree with you. The deprecated one will no go away easily (at
least not before 2.0). So it will stay and warn people for a long
time. This should be properly documented. News and ChangeLog should be
filed accordingly.
-- 
Cedric BAIL

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Daniel Juyung Seo]

On Tue, Jan 10, 2012 at 10:21 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Jan 10, 2012 at 11:03 AM, Iván Briano (Sachiel)
>  wrote:
>> 2012/1/10 Daniel Juyung Seo :
>>> On Fri, Jan 6, 2012 at 11:34 PM, Gustavo Sverzut Barbieri
>>>  wrote:
 On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  wrote:
> Dear all
>
> This patch introduces four new apis about elm_gen{list, grid} item
> class managements.
> itc_add function makes a new item_class for the given widget.
> And itc_del function remove the item_class from the widget.
>
> Most of elm_gen{list, grid} users declare itc(item_class) as a global 
> variable.
> Because itc should be lived at elm_gen{list,grid} item's life cycle.
> It's inconvenient for users. Even some users pass itc.
>
> itc_add makes a new itc. if exact one exists in the given widget, it
> return the previous made itc.
> itc_del remove a itc if its reference count reaches at zero.
>
> Thanks.
>
>
> EAPI Elm_Genlist_Item_Class *
> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>                    Elm_Genlist_Item_Text_Get_Cb text_cb,
>                    Elm_Genlist_Item_Content_Get_Cb content_cb,
>                    Elm_Genlist_Item_State_Get_Cb state_cb,
>                    Elm_Genlist_Item_Del_Cb del_cb);
> EAPI void
> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
> EAPI Elm_Gengrid_Item_Class *
> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
>                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
>                    Elm_Gengrid_Item_State_Get_Cb state_cb,
>                    Elm_Gengrid_Item_Del_Cb del_cb);
> EAPI void
> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);

 I dislike it, one can easily do this kind of stuff using item_del_cb().
>>>

 And really, majority of developers should NEVER use this, the global
 static-const is the correct way to go, making sure memory is live,
 unchanged, no mallocs, etc.
>>>
>>> Thanks for your reply. This patch has an assumption that application
>>> can alloc itc memory dynamically.
>>> If itc-dynamic-allocation is not recommended, do you have to use
>>> global variable for itc?
>>> For a huge app that uses many c sources, we can't force them to use
>>> global static :(
>>>
>>

Ok thanks for the reply

>> You are making a function to return a pre-made class for others to use?
>> Keep the class static to the function, return a pointer to it.
>
> exactly, it just need to be static, not global. It is also recommended
> to be "const", but it is not mandatory.

So I can guide apps to declare item class static to the function and
export the pointer.
Is this the only good way to do this?
In my experience, many application developers alloc item class memory
dynamically.

Daniel Juyung Seo (SeoZ)

>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Cedric BAIL]

On Fri, Jan 6, 2012 at 5:14 PM, Gustavo Sverzut Barbieri
 wrote:
> On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL  wrote:
>> On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL  wrote:
 On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
  wrote:
> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  wrote:
>> Dear all
>>
>> This patch introduces four new apis about elm_gen{list, grid} item
>> class managements.
>> itc_add function makes a new item_class for the given widget.
>> And itc_del function remove the item_class from the widget.
>>
>> Most of elm_gen{list, grid} users declare itc(item_class) as a global 
>> variable.
>> Because itc should be lived at elm_gen{list,grid} item's life cycle.
>> It's inconvenient for users. Even some users pass itc.
>>
>> itc_add makes a new itc. if exact one exists in the given widget, it
>> return the previous made itc.
>> itc_del remove a itc if its reference count reaches at zero.
>>
>> Thanks.
>>
>>
>> EAPI Elm_Genlist_Item_Class *
>> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>>                    Elm_Genlist_Item_Text_Get_Cb text_cb,
>>                    Elm_Genlist_Item_Content_Get_Cb content_cb,
>>                    Elm_Genlist_Item_State_Get_Cb state_cb,
>>                    Elm_Genlist_Item_Del_Cb del_cb);
>> EAPI void
>> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
>> EAPI Elm_Gengrid_Item_Class *
>> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>>                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
>>                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
>>                    Elm_Gengrid_Item_State_Get_Cb state_cb,
>>                    Elm_Gengrid_Item_Del_Cb del_cb);
>> EAPI void
>> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>
> I dislike it, one can easily do this kind of stuff using item_del_cb().
>
> And really, majority of developers should NEVER use this, the global
> static-const is the correct way to go, making sure memory is live,
> unchanged, no mallocs, etc.
>
> Who may use this is bindings, like Python, JavaScript and that's it.
> They have better ways to manage it.

 Yes and no. The current API sucks because it's not futur proof. I
 don't like the proposal either, because it doesn't solve that issue
 either.

 My current idea is to have something like that :

 EAPI Elm_Genlist_Item_Class *elm_genlist_itc_new(void);
 EAPI void elm_genlist_itc_free(Elm_Genlist_Item_Class *itc);

 struct _Elm_Genlist_Item_Class
 {
   int magic;
   int refcount;
   int struc_size;
   const char *item_style;
   struct {
       ...
   } func;
 };

 The _new function call return a clean itc with all pointer set to
 zero. With the struct_size, the application could know if elementary
 is recent enough for him or not. The _free call just reduce the
 refcount of the itc. So it is possible to have backward and forward
 compatibility with time. Not the case with the current API. And yes,
 it would not be possible to give a static pointer once this is done.
>>>
>>> That can be easily solved right now by introduction of version member
>>> in the structure. The allocation has nothing to help here. Magic and
>>> version will replicate themselves.
>>>
>>> You can have init macros, like we have for Evas_Smart_Class.
>>
>> I don't remember why, but we have version info in eet to, and they are 
>> painfull.
>>
>> From an application perspective, it make it impossible to be backward
>> compatible. But that's the only think I can think of right now.
>
> And how are you helping this? This just makes *LIB* authors lazier. To
> keep things without breaking:
>
>  - memory to be used must be >= current, so every time memory should
> increase size of class.
>  - existing members must be preserved at the binary/concept level.
> While you can easily rename stuff (human/compiler interface, not
> runtime), you cannot change the types (if callback, parameters or
> return).
>  - you cannot reorder the members

Agreed on every thing.

> If that is true, with the "allocation" you want, you just get the size
> to be bigger, so library can surely access:
>      cls->new_member_app_does_not_know_about
> Without worrying. If using the version size you'd have to do:
>      if (cls->vesion >= VERSION_APP_DOES_NOT_KNOW_ABOUT)
>          cls->new_member_app_does_not_know_about
> And they work as well!
>
> The second approach is more correct, as zero/NULL/false not
> necessarily is ignored by the library and may affect the behavior, so
> you would need to check it anyway in those cases.
>
> The first case is said to be more reliable as you allocated the 

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

[Youness Alaoui]

Alright, we reached the deadline (actually it was yesterday but I was busy)
and there's still no real agreement about this, however it seems most of
you want the patch reverted, so I will remove it and document it properly.

Thanks for your input.

On Mon, Jan 9, 2012 at 5:14 PM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:

> Bruno, while your example is valid, it's not how it will usually be. Most
> of the time people will use animations, which are bound to keyboard/mouse
> events.
> In my code for example, I can scroll a list using the arrow keys, but if
> you press the arrow twice, then two signals are sent, thus canceling the
> first animation.so the state of the swalowed object is undefined as it all
> depends on the elapsed milliseconds between the first and second press of
> the arrow key. I consider this a race condition.
> I also doubt that anyone is using edje, then suddenly unswallows the
> object and decides to keep it there and start to handle it manually in C.If
> he wanted to handle it in C directly, it wouldn't have been a swallowed
> part in the first place.
> i don't disagree though that this might chance the behavior of some really
> rare apps.
> As for trusting the .edj, you'd trust it to have specific groups/parts and
> handle/send specific signals, but you can't trust it to have an object as a
> specific position. The whole purpose of the edj is to allow the UI dev to
> decide where to position everything, what sizes to give them and what
> states.
>
> On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly wrote:
>
>> On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL  wrote:
>> > On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly 
>> wrote:
>> >> On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL 
>> wrote:
>> >>> On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly 
>> wrote:
>>  On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL 
>> wrote:
>> > On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly 
>> wrote:
>> >> On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL 
>> wrote:
>> >>> On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park 
>> wrote:
>>  I think both are no problems if it has a documentation.
>>  But your patch may break applications already released.
>>  It will be better to apply your patch when major version is
>> changed.
>> >>>
>> >>> As I say, current behaviour is undefined. If you go out of an
>> >>> animation (defined in the edj itself) in any state (hidden, moved,
>> >>> resized, whatever), it will stay in that state. But this is
>> completly
>> >>> random and not defined (as in, depend on an external file). Now I
>> do
>> >>> like the raster proposal with an orphaned flag as it is the only
>> sane
>> >>> way to detect any leak. Relying on an undefined visual artefact
>> would
>> >>> not help at all.
>> >>
>> >> It isn't documented. But it's defined, IMHO, since you can predict
>> it.
>> >> As you said, in an animation it will keep the state, if it was
>> >> visible, it will stay visible.
>> >> So applications can be considering a unswallowed object will be
>> >> visible, since it was visible, and now it will be hidden.
>> >
>> > No, as it is defined in the theme, it doesn't depend on the
>> > application. If you change the theme, the animation, anything in the
>> > .edj, it will change the behaviour in the application itself. It's
>> > full of race condition. There is no sane way to expect any kind of
>> > behaviour in the app. It is definitivly an undefined behaviour, as
>> > their is no way you could know the state of the object without
>> > requesting it after the unswallow.
>> 
>>  OK, my concept of application is code and theme.
>>  Anyway, a simple case is to add an rectangle to a swallow in a
>> layout.
>>  I've attached a quick example. As you can see, no luck required.
>> After
>>  3 seconds the rectangle is unswallowed and displayed at 0,0.
>> >>>
>> >>> Ok, I see the difference. From my point of view, the application
>> >>> should never trust an edj file. So if I can break your "consistent"
>> >>> behaviour by just touching the edc file, then their is a bug in the
>> >>> application from my point of view. In your example. I just need to set
>> >>> visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break
>> >>> your app. So you are just lucky that no one touched your edc file.
>> >>
>> >> Ok, but don't you trust the edj file will have a swallow with name "X"
>> ?
>> >> It's easy to break an application changing the edj if you want to do
>> so.
>> >
>> > You know that edje_object_part_swallow return an EINA_BOOL, do you ?
>>
>> I do, you can print something in your terminal and quit the
>> application. What doesn't mean it is not working as intended.
>>
>> Anyway, there are signals that should be emitted to code and you don't
>> emit that on your theme. So it will break your application and you
>> can't detect.
>> Going further, you can make every part

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib

[Vincent Torri]

On Tue, Jan 10, 2012 at 2:19 PM, Gustavo Sverzut Barbieri
 wrote:
> On Tue, Jan 10, 2012 at 6:58 AM, Vincent Torri  
> wrote:
>> NEWS ? ChangeLog ?
>
> don't think it's worth. When we remove the deprecated we add it.

but you added a function, right ?

Vincent

>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Hyoyoung Chang]

On Tue, Jan 10, 2012 at 11:03 PM, Cedric BAIL  wrote:
> On Fri, Jan 6, 2012 at 5:14 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL  wrote:
>>> On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
>>>  wrote:
 On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL  wrote:
> On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  
>> wrote:
>>> Dear all
>>>
>>> This patch introduces four new apis about elm_gen{list, grid} item
>>> class managements.
>>> itc_add function makes a new item_class for the given widget.
>>> And itc_del function remove the item_class from the widget.
>>>
>>> Most of elm_gen{list, grid} users declare itc(item_class) as a global 
>>> variable.
>>> Because itc should be lived at elm_gen{list,grid} item's life cycle.
>>> It's inconvenient for users. Even some users pass itc.
>>>
>>> itc_add makes a new itc. if exact one exists in the given widget, it
>>> return the previous made itc.
>>> itc_del remove a itc if its reference count reaches at zero.
>>>
>>> Thanks.
>>>
>>>
>>> EAPI Elm_Genlist_Item_Class *
>>> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Genlist_Item_Text_Get_Cb text_cb,
>>>                    Elm_Genlist_Item_Content_Get_Cb content_cb,
>>>                    Elm_Genlist_Item_State_Get_Cb state_cb,
>>>                    Elm_Genlist_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
>>> EAPI Elm_Gengrid_Item_Class *
>>> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
>>>                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
>>>                    Elm_Gengrid_Item_State_Get_Cb state_cb,
>>>                    Elm_Gengrid_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>
>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>>
>> And really, majority of developers should NEVER use this, the global
>> static-const is the correct way to go, making sure memory is live,
>> unchanged, no mallocs, etc.
>>
>> Who may use this is bindings, like Python, JavaScript and that's it.
>> They have better ways to manage it.
>
> Yes and no. The current API sucks because it's not futur proof. I
> don't like the proposal either, because it doesn't solve that issue
> either.
>
> My current idea is to have something like that :
>
> EAPI Elm_Genlist_Item_Class *elm_genlist_itc_new(void);
> EAPI void elm_genlist_itc_free(Elm_Genlist_Item_Class *itc);
>
> struct _Elm_Genlist_Item_Class
> {
>   int magic;
>   int refcount;
>   int struc_size;
>   const char *item_style;
>   struct {
>       ...
>   } func;
> };
>
> The _new function call return a clean itc with all pointer set to
> zero. With the struct_size, the application could know if elementary
> is recent enough for him or not. The _free call just reduce the
> refcount of the itc. So it is possible to have backward and forward
> compatibility with time. Not the case with the current API. And yes,
> it would not be possible to give a static pointer once this is done.

 That can be easily solved right now by introduction of version member
 in the structure. The allocation has nothing to help here. Magic and
 version will replicate themselves.

 You can have init macros, like we have for Evas_Smart_Class.
>>>
>>> I don't remember why, but we have version info in eet to, and they are 
>>> painfull.
>>>
>>> From an application perspective, it make it impossible to be backward
>>> compatible. But that's the only think I can think of right now.
>>
>> And how are you helping this? This just makes *LIB* authors lazier. To
>> keep things without breaking:
>>
>>  - memory to be used must be >= current, so every time memory should
>> increase size of class.
>>  - existing members must be preserved at the binary/concept level.
>> While you can easily rename stuff (human/compiler interface, not
>> runtime), you cannot change the types (if callback, parameters or
>> return).
>>  - you cannot reorder the members
>
> Agreed on every thing.
>
>> If that is true, with the "allocation" you want, you just get the size
>> to be bigger, so library can surely access:
>>      cls->new_member_app_does_not_know_about
>> Without worrying. If using the version size you'd have to do:
>>      if (cls->vesion >= VERSION_APP_DOES_NOT_KNOW_ABOUT)
>>          cls->new_member_app_does_not_know_about
>> And they work as well!
>>
>> The second approach is more correct, as zero/NULL/false not
>> necessari

Re: [E-devel] E SVN: seoz trunk/elementary/src/lib

[Sachiel]

2012/1/10 Enlightenment SVN :
> Log:
> enki: Turn off edje_cc verbose mode.
>

This patch is not doing that. And it looks wrong. On many levels.

> Author:       seoz
> Date:         2012-01-10 07:34:04 -0800 (Tue, 10 Jan 2012)
> New Revision: 67016
> Trac:         http://trac.enlightenment.org/e/changeset/67016
>
> Modified:
>  trunk/elementary/src/lib/elm_main.c
>
> Modified: trunk/elementary/src/lib/elm_main.c
> ===
> --- trunk/elementary/src/lib/elm_main.c 2012-01-10 11:57:09 UTC (rev 67015)
> +++ trunk/elementary/src/lib/elm_main.c 2012-01-10 15:34:04 UTC (rev 67016)
> @@ -2084,18 +2084,6 @@
>  }
>
>  EAPI void
> -elm_object_access_info_set(Evas_Object *obj, const char *txt)
> -{
> -   elm_widget_access_info_set(obj, txt);
> -}
> -
> -EAPI Evas_Object *
> -elm_object_name_find(const Evas_Object *obj, const char *name, int recurse)
> -{
> -   return elm_widget_name_find(obj, name, recurse);
> -}
> -
> -EAPI void
>  elm_object_item_access_info_set(Elm_Object_Item *it, const char *txt)
>  {
>    _elm_widget_item_access_info_set((Elm_Widget_Item *) it, txt);
> @@ -2119,17 +2107,20 @@
>    _elm_widget_item_signal_emit((Elm_Widget_Item *) it, emission, source);
>  }
>
> -EAPI void elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool 
> disabled)
> +EAPI void
> +elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool disabled)
>  {
>    _elm_widget_item_disabled_set((Elm_Widget_Item *) it, disabled);
>  }
>
> -EAPI Eina_Bool elm_object_item_disabled_get(const Elm_Object_Item *it)
> +EAPI Eina_Bool
> +elm_object_item_disabled_get(const Elm_Object_Item *it)
>  {
>    return _elm_widget_item_disabled_get((Elm_Widget_Item *) it);
>  }
>
> -EAPI void elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb 
> del_cb)
> +EAPI void
> +elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb del_cb)
>  {
>    _elm_widget_item_del_cb_set((Elm_Widget_Item *) it, del_cb);
>  }
>
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: seoz trunk/elementary/src/lib

[Daniel Juyung Seo]

oh my god!
sorry i will revert this and commit a right patch.
On Jan 11, 2012 5:09 AM, "Iván Briano (Sachiel)"  wrote:

> 2012/1/10 Enlightenment SVN :
> > Log:
> > enki: Turn off edje_cc verbose mode.
> >
>
> This patch is not doing that. And it looks wrong. On many levels.
>
> > Author:   seoz
> > Date: 2012-01-10 07:34:04 -0800 (Tue, 10 Jan 2012)
> > New Revision: 67016
> > Trac: http://trac.enlightenment.org/e/changeset/67016
> >
> > Modified:
> >  trunk/elementary/src/lib/elm_main.c
> >
> > Modified: trunk/elementary/src/lib/elm_main.c
> > ===
> > --- trunk/elementary/src/lib/elm_main.c 2012-01-10 11:57:09 UTC (rev
> 67015)
> > +++ trunk/elementary/src/lib/elm_main.c 2012-01-10 15:34:04 UTC (rev
> 67016)
> > @@ -2084,18 +2084,6 @@
> >  }
> >
> >  EAPI void
> > -elm_object_access_info_set(Evas_Object *obj, const char *txt)
> > -{
> > -   elm_widget_access_info_set(obj, txt);
> > -}
> > -
> > -EAPI Evas_Object *
> > -elm_object_name_find(const Evas_Object *obj, const char *name, int
> recurse)
> > -{
> > -   return elm_widget_name_find(obj, name, recurse);
> > -}
> > -
> > -EAPI void
> >  elm_object_item_access_info_set(Elm_Object_Item *it, const char *txt)
> >  {
> >_elm_widget_item_access_info_set((Elm_Widget_Item *) it, txt);
> > @@ -2119,17 +2107,20 @@
> >_elm_widget_item_signal_emit((Elm_Widget_Item *) it, emission,
> source);
> >  }
> >
> > -EAPI void elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool
> disabled)
> > +EAPI void
> > +elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool disabled)
> >  {
> >_elm_widget_item_disabled_set((Elm_Widget_Item *) it, disabled);
> >  }
> >
> > -EAPI Eina_Bool elm_object_item_disabled_get(const Elm_Object_Item *it)
> > +EAPI Eina_Bool
> > +elm_object_item_disabled_get(const Elm_Object_Item *it)
> >  {
> >return _elm_widget_item_disabled_get((Elm_Widget_Item *) it);
> >  }
> >
> > -EAPI void elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb
> del_cb)
> > +EAPI void
> > +elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb del_cb)
> >  {
> >_elm_widget_item_del_cb_set((Elm_Widget_Item *) it, del_cb);
> >  }
> >
> >
> >
> --
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: seoz trunk/elementary/src/lib

[Daniel Juyung Seo]

Reverted!
Thanks for reporting and sorry for my mistake.

Daniel Juyung Seo (SeoZ)

On Wed, Jan 11, 2012 at 7:32 AM, Daniel Juyung Seo  wrote:
> oh my god!
> sorry i will revert this and commit a right patch.
>
> On Jan 11, 2012 5:09 AM, "Iván Briano (Sachiel)"  wrote:
>>
>> 2012/1/10 Enlightenment SVN :
>> > Log:
>> > enki: Turn off edje_cc verbose mode.
>> >
>>
>> This patch is not doing that. And it looks wrong. On many levels.
>>
>> > Author:       seoz
>> > Date:         2012-01-10 07:34:04 -0800 (Tue, 10 Jan 2012)
>> > New Revision: 67016
>> > Trac:         http://trac.enlightenment.org/e/changeset/67016
>> >
>> > Modified:
>> >  trunk/elementary/src/lib/elm_main.c
>> >
>> > Modified: trunk/elementary/src/lib/elm_main.c
>> > ===
>> > --- trunk/elementary/src/lib/elm_main.c 2012-01-10 11:57:09 UTC (rev
>> > 67015)
>> > +++ trunk/elementary/src/lib/elm_main.c 2012-01-10 15:34:04 UTC (rev
>> > 67016)
>> > @@ -2084,18 +2084,6 @@
>> >  }
>> >
>> >  EAPI void
>> > -elm_object_access_info_set(Evas_Object *obj, const char *txt)
>> > -{
>> > -   elm_widget_access_info_set(obj, txt);
>> > -}
>> > -
>> > -EAPI Evas_Object *
>> > -elm_object_name_find(const Evas_Object *obj, const char *name, int
>> > recurse)
>> > -{
>> > -   return elm_widget_name_find(obj, name, recurse);
>> > -}
>> > -
>> > -EAPI void
>> >  elm_object_item_access_info_set(Elm_Object_Item *it, const char *txt)
>> >  {
>> >    _elm_widget_item_access_info_set((Elm_Widget_Item *) it, txt);
>> > @@ -2119,17 +2107,20 @@
>> >    _elm_widget_item_signal_emit((Elm_Widget_Item *) it, emission,
>> > source);
>> >  }
>> >
>> > -EAPI void elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool
>> > disabled)
>> > +EAPI void
>> > +elm_object_item_disabled_set(Elm_Object_Item *it, Eina_Bool disabled)
>> >  {
>> >    _elm_widget_item_disabled_set((Elm_Widget_Item *) it, disabled);
>> >  }
>> >
>> > -EAPI Eina_Bool elm_object_item_disabled_get(const Elm_Object_Item *it)
>> > +EAPI Eina_Bool
>> > +elm_object_item_disabled_get(const Elm_Object_Item *it)
>> >  {
>> >    return _elm_widget_item_disabled_get((Elm_Widget_Item *) it);
>> >  }
>> >
>> > -EAPI void elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb
>> > del_cb)
>> > +EAPI void
>> > +elm_object_item_del_cb_set(Elm_Object_Item *it, Evas_Smart_Cb del_cb)
>> >  {
>> >    _elm_widget_item_del_cb_set((Elm_Widget_Item *) it, del_cb);
>> >  }
>> >
>> >
>> >
>> > --
>> > Write once. Port to many.
>> > Get the SDK and tools to simplify cross-platform app development. Create
>> > new or port existing apps to sell to consumers worldwide. Explore the
>> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> > http://p.sf.net/sfu/intel-appdev
>> > ___
>> > enlightenment-svn mailing list
>> > enlightenment-...@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>>
>> --
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_store - fix eina_lock ptr handling

[Daniel Juyung Seo]

In SVN!
 http://trac.enlightenment.org/e/changeset/67032

Thanks!

On Tue, Jan 10, 2012 at 8:40 PM, Hyoyoung Chang  wrote:
> It's another patch file that describes a method to get a store example files.
> If it's ok, plz commit it.
> Thanks
>
> On Tue, Jan 10, 2012 at 8:15 PM, Hyoyoung Chang  wrote:
>> Dear all,
>>
>> When i run 'store' menu in elementary_test, i met some segfault.
>> it's due to inappropriate eina_lock ptr handling.
>>
>> Thanks
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_store - fix eina_lock ptr handling

[Daniel Juyung Seo]

This is right patch.
In SVN!
http://trac.enlightenment.org/e/changeset/67030

Thanks!

Daniel Juyung Seo (SeoZ)

On Tue, Jan 10, 2012 at 8:15 PM, Hyoyoung Chang  wrote:
> Dear all,
>
> When i run 'store' menu in elementary_test, i met some segfault.
> it's due to inappropriate eina_lock ptr handling.
>
> Thanks
>
> --
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib

[Gustavo Sverzut Barbieri]

On Tue, Jan 10, 2012 at 1:31 PM, Vincent Torri  wrote:
> On Tue, Jan 10, 2012 at 2:19 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Tue, Jan 10, 2012 at 6:58 AM, Vincent Torri  
>> wrote:
>>> NEWS ? ChangeLog ?
>>
>> don't think it's worth. When we remove the deprecated we add it.
>
> but you added a function, right ?

static inline one, as the _get() variant. It is just a helper for
direct pointer access.

I don't think it is worth because the compiler itself will warn about
the deprecation, it is no big deal.

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

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Gustavo Sverzut Barbieri]

On Tue, Jan 10, 2012 at 12:03 PM, Cedric BAIL  wrote:
> On Fri, Jan 6, 2012 at 5:14 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL  wrote:
>>> On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
>>>  wrote:
 On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL  wrote:
> On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  
>> wrote:
>>> Dear all
>>>
>>> This patch introduces four new apis about elm_gen{list, grid} item
>>> class managements.
>>> itc_add function makes a new item_class for the given widget.
>>> And itc_del function remove the item_class from the widget.
>>>
>>> Most of elm_gen{list, grid} users declare itc(item_class) as a global 
>>> variable.
>>> Because itc should be lived at elm_gen{list,grid} item's life cycle.
>>> It's inconvenient for users. Even some users pass itc.
>>>
>>> itc_add makes a new itc. if exact one exists in the given widget, it
>>> return the previous made itc.
>>> itc_del remove a itc if its reference count reaches at zero.
>>>
>>> Thanks.
>>>
>>>
>>> EAPI Elm_Genlist_Item_Class *
>>> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Genlist_Item_Text_Get_Cb text_cb,
>>>                    Elm_Genlist_Item_Content_Get_Cb content_cb,
>>>                    Elm_Genlist_Item_State_Get_Cb state_cb,
>>>                    Elm_Genlist_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
>>> EAPI Elm_Gengrid_Item_Class *
>>> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>>>                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
>>>                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
>>>                    Elm_Gengrid_Item_State_Get_Cb state_cb,
>>>                    Elm_Gengrid_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>
>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>>
>> And really, majority of developers should NEVER use this, the global
>> static-const is the correct way to go, making sure memory is live,
>> unchanged, no mallocs, etc.
>>
>> Who may use this is bindings, like Python, JavaScript and that's it.
>> They have better ways to manage it.
>
> Yes and no. The current API sucks because it's not futur proof. I
> don't like the proposal either, because it doesn't solve that issue
> either.
>
> My current idea is to have something like that :
>
> EAPI Elm_Genlist_Item_Class *elm_genlist_itc_new(void);
> EAPI void elm_genlist_itc_free(Elm_Genlist_Item_Class *itc);
>
> struct _Elm_Genlist_Item_Class
> {
>   int magic;
>   int refcount;
>   int struc_size;
>   const char *item_style;
>   struct {
>       ...
>   } func;
> };
>
> The _new function call return a clean itc with all pointer set to
> zero. With the struct_size, the application could know if elementary
> is recent enough for him or not. The _free call just reduce the
> refcount of the itc. So it is possible to have backward and forward
> compatibility with time. Not the case with the current API. And yes,
> it would not be possible to give a static pointer once this is done.

 That can be easily solved right now by introduction of version member
 in the structure. The allocation has nothing to help here. Magic and
 version will replicate themselves.

 You can have init macros, like we have for Evas_Smart_Class.
>>>
>>> I don't remember why, but we have version info in eet to, and they are 
>>> painfull.
>>>
>>> From an application perspective, it make it impossible to be backward
>>> compatible. But that's the only think I can think of right now.
>>
>> And how are you helping this? This just makes *LIB* authors lazier. To
>> keep things without breaking:
>>
>>  - memory to be used must be >= current, so every time memory should
>> increase size of class.
>>  - existing members must be preserved at the binary/concept level.
>> While you can easily rename stuff (human/compiler interface, not
>> runtime), you cannot change the types (if callback, parameters or
>> return).
>>  - you cannot reorder the members
>
> Agreed on every thing.
>
>> If that is true, with the "allocation" you want, you just get the size
>> to be bigger, so library can surely access:
>>      cls->new_member_app_does_not_know_about
>> Without worrying. If using the version size you'd have to do:
>>      if (cls->vesion >= VERSION_APP_DOES_NOT_KNOW_ABOUT)
>>          cls->new_member_app_does_not_know_about
>> And they work as well!
>>
>> The second approach is more correct, as zero/NULL/false not
>> necessari

Re: [E-devel] [Patch][elm_map] Fix zoom & rotated coordinates bug

[The Rasterman]

On Mon, 9 Jan 2012 17:28:21 +0900 Bluezery  said:

sorry - been busy for the past week or so and havent had time to deal with my
backlog. i'm onto it now.

comment:
  elm_map_convert_canvas_into_geo()
-> should rename to be more efl strict oo like:
  elm_map_canvas_to_geo_convert()

while i'm at it:
  elm_map_utils_rotate_coord()
should be
  elm_map_utils_coord_rotate()

could you fix this? :)

> After consideration, I think that elm_map_utils_size_get() and
> elm_map_utils_region_get() is not needed for users. because only
> functions related to geographic coordinates are only concern of users.
> And converting func. from canvas to geo is needed for finding exact
> geo-coordinates in canvas area.
> So, I have modified patches.
> 
> Anyway, no one may interested in elm_maps...
> Please review this patchplz...
> 
> 2012/1/2 Bluezery :
> > Hi,
> >
> > In my point of view, elm_map did not consider zooming & rotation by
> > using Evas_Map initially.
> > There are no problems if you use only elm_map_zoom_set(). But if you
> > use pinch gesture or wheel to do subtle zooming & rotating, the
> > calculations of coordinates are not correct currently.
> >
> > I have fixed these problem and also made some utility APIs for user
> > convenience. I made following 3 APIs.
> > 1. elm_map_utils_size_get()
> > Currently users can only get integer zoom level by using elm_map_zoom_get().
> > So if user want to calculate full map size, user should calculate
> > pow(2.0, zoom level) * tile size.  Furthermore, user assumes tile size
> > as 256. (tile size can be changed!!)
> > Also it's not correct sometimes because Evas_map is used for subtle
> > zooming between zoom levels.
> > Above APIs return correct full map size.
> >
> > 2. elm_map_utils_region_get()
> > It can used for getting left top coordinates, center coordinates and
> > width, height of currently shown map area.
> >
> > 3. elm_map_utils_convert_canvas_into_geo()
> > Currently it is hard to converting x, y coordinates to geographical
> > longitude, latitude because of subtle zooming & rotating.
> > If use wants to get it, user uses combination of above functions and
> > more. It is harsh job.
> > This function is used for getting longitude, latitude from x, y
> > coordinates of current viewport.
> >
> > Test application can be brief by using above functions .
> >
> > Please review this patch.
> >
> > --
> > BRs,
> > Kim.
> 
> 
> 
> -- 
> BRs,
> Kim.


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


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions

[Gustavo Sverzut Barbieri]

On Tue, Jan 10, 2012 at 2:23 PM, Hyoyoung Chang  wrote:
> On Tue, Jan 10, 2012 at 11:03 PM, Cedric BAIL  wrote:
>> On Fri, Jan 6, 2012 at 5:14 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL  wrote:
 On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
  wrote:
> On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL  wrote:
>> On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang  
>>> wrote:
 Dear all

 This patch introduces four new apis about elm_gen{list, grid} item
 class managements.
 itc_add function makes a new item_class for the given widget.
 And itc_del function remove the item_class from the widget.

 Most of elm_gen{list, grid} users declare itc(item_class) as a global 
 variable.
 Because itc should be lived at elm_gen{list,grid} item's life cycle.
 It's inconvenient for users. Even some users pass itc.

 itc_add makes a new itc. if exact one exists in the given widget, it
 return the previous made itc.
 itc_del remove a itc if its reference count reaches at zero.

 Thanks.


 EAPI Elm_Genlist_Item_Class *
 elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
                    Elm_Genlist_Item_Text_Get_Cb text_cb,
                    Elm_Genlist_Item_Content_Get_Cb content_cb,
                    Elm_Genlist_Item_State_Get_Cb state_cb,
                    Elm_Genlist_Item_Del_Cb del_cb);
 EAPI void
 elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
 EAPI Elm_Gengrid_Item_Class *
 elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
                    Elm_Gengrid_Item_Text_Get_Cb text_cb,
                    Elm_Gengrid_Item_Content_Get_Cb content_cb,
                    Elm_Gengrid_Item_State_Get_Cb state_cb,
                    Elm_Gengrid_Item_Del_Cb del_cb);
 EAPI void
 elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>>
>>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>>>
>>> And really, majority of developers should NEVER use this, the global
>>> static-const is the correct way to go, making sure memory is live,
>>> unchanged, no mallocs, etc.
>>>
>>> Who may use this is bindings, like Python, JavaScript and that's it.
>>> They have better ways to manage it.
>>
>> Yes and no. The current API sucks because it's not futur proof. I
>> don't like the proposal either, because it doesn't solve that issue
>> either.
>>
>> My current idea is to have something like that :
>>
>> EAPI Elm_Genlist_Item_Class *elm_genlist_itc_new(void);
>> EAPI void elm_genlist_itc_free(Elm_Genlist_Item_Class *itc);
>>
>> struct _Elm_Genlist_Item_Class
>> {
>>   int magic;
>>   int refcount;
>>   int struc_size;
>>   const char *item_style;
>>   struct {
>>       ...
>>   } func;
>> };
>>
>> The _new function call return a clean itc with all pointer set to
>> zero. With the struct_size, the application could know if elementary
>> is recent enough for him or not. The _free call just reduce the
>> refcount of the itc. So it is possible to have backward and forward
>> compatibility with time. Not the case with the current API. And yes,
>> it would not be possible to give a static pointer once this is done.
>
> That can be easily solved right now by introduction of version member
> in the structure. The allocation has nothing to help here. Magic and
> version will replicate themselves.
>
> You can have init macros, like we have for Evas_Smart_Class.

 I don't remember why, but we have version info in eet to, and they are 
 painfull.

 From an application perspective, it make it impossible to be backward
 compatible. But that's the only think I can think of right now.
>>>
>>> And how are you helping this? This just makes *LIB* authors lazier. To
>>> keep things without breaking:
>>>
>>>  - memory to be used must be >= current, so every time memory should
>>> increase size of class.
>>>  - existing members must be preserved at the binary/concept level.
>>> While you can easily rename stuff (human/compiler interface, not
>>> runtime), you cannot change the types (if callback, parameters or
>>> return).
>>>  - you cannot reorder the members
>>
>> Agreed on every thing.
>>
>>> If that is true, with the "allocation" you want, you just get the size
>>> to be bigger, so library can surely access:
>>>      cls->new_member_app_does_not_know_about
>>> Without worrying. If using the version size you'd have to do:
>>>      if (cls->vesion >= VERSION_APP_DOES_NO

Re: [E-devel] [Patch] elc_ctxpopup, add restacking feature

[The Rasterman]

On Mon, 2 Jan 2012 20:08:47 +0900 Kim Shinwoo  said:

in svn! thanks! :)

> Hey,
> 
> I have attached example code for checking restacking feature of ctxpopup.
> Please review the code and give any feedbacks. Thanks.
> 
> 
> 2011/12/22 Daniel Juyung Seo 
> 
> > We need more test! Anyhow thanks!
> >
> > Daniel Juyung Seo (SeoZ)
> >
> > On Thu, Dec 22, 2011 at 10:34 AM, Michael Blumenkrantz
> >  wrote:
> > > On Thu, 22 Dec 2011 10:31:50 +0900
> > > Carsten Haitzler (The Rasterman)  wrote:
> > >
> > >> On Thu, 22 Dec 2011 10:22:05 +0900 Kim Shinwoo 
> > said:
> > >>
> > >> > Wow~ The test code also in the SVN. It is just for checking the
> > restacking
> > >> > feature.
> > >> > It does not (definitely not) have to in the SVN as I mentioned in the
> > >> > previous mail: "please throw the test example away! :-)"
> > >> > So, you guys want to add new and GOOD test code or remove it?
> > >>
> > >> i like there being tests :)
> > >>
> > >> > 2011년 12월 21일 오후 6:18, ChunEon Park 님의 말:
> > >> >
> > >> > > Code does not matter.
> > >> > > But test working looks like bug.
> > >> > > It creates label but never remove them until close the window.
> > >> > > cinoo should consider other way for the test case.
> > >> > > 
> > >> > > -Regards, Hermet-
> > >> > >
> > >> > > -Original Message-
> > >> > > From: "Carsten Haitzler"
> > >> > > To: "Enlightenment developer list"&
> > >> > > lt;enlightenment-devel@lists.sourceforge.net>
> > >> > > Cc: "ChunEon Park"; "cnook"&
> > lt;kimci...@gmail.com
> > >> > > >
> > >> > > Sent: 11-12-21(수) 18:12:12
> > >> > > Subject: Re: [E-devel] [Patch] elc_ctxpopup, add restacking feature
> > >> > > On Wed, 21 Dec 2011 17:58:33 +0900 ChunEon Park > >
> > >> > > said:
> > >> > > bug? the patch looked fine to me other than not deleting timer if
> > ctxpopup
> > >> > > is
> > >> > > deleted...
> > >> > > > The test looks like bug!
> > >> > > > I don't wanna this kind of changes pushed in.
> > >> > > > 
> > >> > > > -Regards, Hermet-
> > >> > > >
> > >> > > > -Original Message-
> > >> > > > From: "Carsten Haitzler"
> > >> > > > To: "Enlightenment developer
> > >> > > > list" Cc:
> > >> > > > "cnook" Sent: 11-12-21(수) 15:35:00
> > >> > > > Subject: Re: [E-devel] [Patch] elc_ctxpopup, add restacking
> > feature
> > >> > > > On Tue, 20 Dec 2011 10:27:46 +0900 cnook  > >
> > >> > > said:
> > >> > > > in! :)
> > >> > > > > Dear All, Hello
> > >> > > > >
> > >> > > > > I have attached two files, one is the patch(*.diff) for adding
> > >> > > > > restacking feature to the ctxpopup.
> > >> > > > > The other is test example(*.TEST_EXAMPLE). You can test on the
> > >> > > > > elementary_test > ctxpopup > "Ctxpopup with user content"
> > >> > > > > And click the button which is labeled "Enlightenment". Then
> > label will
> > >> > > > > overlap the ctxpopup.. The ctxpopup will raise in a little time.
> > >> > > > > Please review the patch and if there is no problem, please
> > throw the
> > >> > > > > test example away! :-)
> > >> > > > >
> > >> > > > > Sincerely,
> > >> > > > > Shinwoo Kim.
> > >> > > > --
> > >> > > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > >> > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > >> > > >
> > >> > >
> > --
> > >> > > > Write once. Port to many.
> > >> > > > Get the SDK and tools to simplify cross-platform app development.
> > Create
> > >> > > > new or port existing apps to sell to consumers worldwide. Explore
> > the
> > >> > > > Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join
> > >> > > > http://p.sf.net/sfu/intel-appdev
> > >> > > > ___
> > >> > > > enlightenment-devel mailing list
> > >> > > > enlightenment-devel@lists.sourceforge.net
> > >> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >> > > >
> > >> > >
> > --
> > >> > > > Write once. Port to many.
> > >> > > > Get the SDK and tools to simplify cross-platform app development.
> > Create
> > >> > > > new or port existing apps to sell to consumers worldwide. Explore
> > the
> > >> > > > Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join
> > >> > > > http://p.sf.net/sfu/intel-appdev
> > >> > > > ___
> > >> > > > 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 

Re: [E-devel] [Patch][elm_map] Fix zoom & rotated coordinates bug

[Bluezery]

Thanks~!

I changed the name
elm_map_convert_canvas_into_geo() --> elm_map_canvas_to_geo_convert()

And I deprecate elm_map_utils_rotate_coord() function.
Instead recommend elm_map_canvas_to_geo_convert() to use in doc.
Acutally, rotation is not needed to know.
Please review again :D

2012/1/11 Carsten Haitzler :
> On Mon, 9 Jan 2012 17:28:21 +0900 Bluezery  said:
>
> sorry - been busy for the past week or so and havent had time to deal with my
> backlog. i'm onto it now.
>
> comment:
>  elm_map_convert_canvas_into_geo()
> -> should rename to be more efl strict oo like:
>  elm_map_canvas_to_geo_convert()
>
> while i'm at it:
>  elm_map_utils_rotate_coord()
> should be
>  elm_map_utils_coord_rotate()
>
> could you fix this? :)
>
>> After consideration, I think that elm_map_utils_size_get() and
>> elm_map_utils_region_get() is not needed for users. because only
>> functions related to geographic coordinates are only concern of users.
>> And converting func. from canvas to geo is needed for finding exact
>> geo-coordinates in canvas area.
>> So, I have modified patches.
>>
>> Anyway, no one may interested in elm_maps...
>> Please review this patchplz...
>>
>> 2012/1/2 Bluezery :
>> > Hi,
>> >
>> > In my point of view, elm_map did not consider zooming & rotation by
>> > using Evas_Map initially.
>> > There are no problems if you use only elm_map_zoom_set(). But if you
>> > use pinch gesture or wheel to do subtle zooming & rotating, the
>> > calculations of coordinates are not correct currently.
>> >
>> > I have fixed these problem and also made some utility APIs for user
>> > convenience. I made following 3 APIs.
>> > 1. elm_map_utils_size_get()
>> > Currently users can only get integer zoom level by using 
>> > elm_map_zoom_get().
>> > So if user want to calculate full map size, user should calculate
>> > pow(2.0, zoom level) * tile size.  Furthermore, user assumes tile size
>> > as 256. (tile size can be changed!!)
>> > Also it's not correct sometimes because Evas_map is used for subtle
>> > zooming between zoom levels.
>> > Above APIs return correct full map size.
>> >
>> > 2. elm_map_utils_region_get()
>> > It can used for getting left top coordinates, center coordinates and
>> > width, height of currently shown map area.
>> >
>> > 3. elm_map_utils_convert_canvas_into_geo()
>> > Currently it is hard to converting x, y coordinates to geographical
>> > longitude, latitude because of subtle zooming & rotating.
>> > If use wants to get it, user uses combination of above functions and
>> > more. It is harsh job.
>> > This function is used for getting longitude, latitude from x, y
>> > coordinates of current viewport.
>> >
>> > Test application can be brief by using above functions .
>> >
>> > Please review this patch.
>> >
>> > --
>> > BRs,
>> > Kim.
>>
>>
>>
>> --
>> BRs,
>> Kim.
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>



-- 
BRs,
Kim.
Index: src/lib/elm_map.c
===
--- src/lib/elm_map.c	(리비전 67035)
+++ src/lib/elm_map.c	(작업 사본)
@@ -2964,6 +2964,72 @@ rotate_end_cb(void *data, void *event_in
return EVAS_EVENT_FLAG_NONE;
 }
 
+static void
+_region_get(Widget_Data *wd, Evas_Coord *x, Evas_Coord *y, Evas_Coord *cx, Evas_Coord *cy, Evas_Coord *w, Evas_Coord *h)
+{
+   EINA_SAFETY_ON_NULL_RETURN(wd);
+   Evas_Coord sx, sy, tx, ty, tcx, tcy, sw, sh, tw, th, rw, rh;
+
+   elm_smart_scroller_child_pos_get(wd->scr, &sx, &sy);
+   elm_smart_scroller_child_viewport_size_get(wd->scr, &sw, &sh);
+   rw = wd->size.w * wd->pinch.level;
+   rh = wd->size.h * wd->pinch.level;
+
+   if (wd->size.w < sw)
+ {
+tw = rw;
+tcx = sx + tw/2;
+tx = sx + (sw - tw)/2;
+ }
+   else
+ {
+tw = sw;
+tcx = (sx + tw/2) * wd->pinch.level;
+tx = tcx - tw/2;
+
+ }
+   if (wd->size.h < sh)
+ {
+th = rh;
+ty = sy + (sh - th)/2;
+tcy = sy + th/2;
+ }
+   else
+ {
+th = sw;
+tcy = (sy + th/2) * wd->pinch.level;
+ty = tcy - th/2;
+ }
+
+   if (x) *x = tx;
+   if (y) *y = ty;
+   if (cx) *cx= tcx;
+   if (cy) *cy = tcy;
+   if (w) *w = tw;
+   if (h) *h = th;
+}
+
+static void
+_coord_rotate(const Evas_Coord x, const Evas_Coord y, const Evas_Coord cx, const Evas_Coord cy, const double degree, Evas_Coord *xx, Evas_Coord *yy)
+{
+   EINA_SAFETY_ON_NULL_RETURN(xx);
+   EINA_SAFETY_ON_NULL_RETURN(yy);
+
+   double r = (degree * M_PI) / 180.0;
+   double tx, ty, ttx, tty;
+
+   tx = x - cx;
+   ty = y - cy;
+
+   ttx = tx * cos(r);
+   tty = tx * sin(r);
+   tx = ttx + (ty * cos(r + M_PI_2));
+   ty = tty + (ty * sin(r + M_PI_2));
+
+   *xx = tx + cx;
+   *yy = ty + cy;
+}
+
 #endif
 
 EAPI Evas_Object *
@@ -3373,17 +3439,16 @@ elm_map_geo_region_get(const Evas_Object
 #ifdef HAVE_ELEMENTARY_ECORE_CON
ELM_CHECK_WIDTYPE(obj, widtype);
Widget_Data *wd = 

Re: [E-devel] E SVN: barbieri IN trunk/eina: . src/include src/lib src/tests

[Lucas De Marchi]

On Wed, Jan 11, 2012 at 12:20 AM, Enlightenment SVN
 wrote:
> Log:
> add eina_value.
>
>  eina value is a generic value storage, it's quite efficient to space
>  (16 bytes) and speed (inlines for basic types).
>
>  It's basically a structure describing how to manage memory
>  (Eina_Value_Type), with default implementation for char, short, int,
>  long, int64_t (and unsigned variants), float, double, stringshare and
>  string.
>
>  If a type 'value_size' is smaller than 8 bytes, it's stored
>  inline. Otherwise a value is allocated and managed.
>
>  Most of the methods are inline, with special handling for char, short,
>  int... Then no extra calls are made, allowing the compiler to optimize
>  them.
>
>  For array of a single type it is recommend to use Eina_Value_Array, as
>  it will efficiently store and access members (just a char if subtype
>  is EINA_VALUE_TYPE_CHAR, etc).
>
>  It can copy itself, compare itself. Including arrays.
>
>  It would be nice to have something that converts between EET and this.
>
>
>
> Author:       barbieri
> Date:         2012-01-10 18:20:26 -0800 (Tue, 10 Jan 2012)
> New Revision: 67035
> Trac:         http://trac.enlightenment.org/e/changeset/67035
>
> Added:
>  trunk/eina/src/include/eina_inline_value.x 
> trunk/eina/src/include/eina_value.h trunk/eina/src/tests/eina_test_value.c
> Modified:
>  trunk/eina/ChangeLog trunk/eina/NEWS trunk/eina/src/include/Eina.h 
> trunk/eina/src/include/Makefile.am trunk/eina/src/include/eina_inarray.h 
> trunk/eina/src/lib/eina_inarray.c trunk/eina/src/lib/eina_main.c 
> trunk/eina/src/lib/eina_value.c trunk/eina/src/tests/Makefile.am 
> trunk/eina/src/tests/eina_suite.c trunk/eina/src/tests/eina_suite.h
>
> Modified: trunk/eina/ChangeLog
> ===
> --- trunk/eina/ChangeLog        2012-01-11 02:06:07 UTC (rev 67034)
> +++ trunk/eina/ChangeLog        2012-01-11 02:20:26 UTC (rev 67035)
> @@ -192,3 +192,4 @@
>  2012-01-09  Gustavo Barbieri
>
>        * Add eina_inarray data type.
> +       * Add eina_value data type (generic value storage).
>
> Modified: trunk/eina/NEWS
> ===
> --- trunk/eina/NEWS     2012-01-11 02:06:07 UTC (rev 67034)
> +++ trunk/eina/NEWS     2012-01-11 02:20:26 UTC (rev 67035)
> @@ -12,6 +12,7 @@
>     * eina_file_map_faulted API
>     * Xattr iterator for Eina_File : eina_file_xattr_get and 
> eina_file_xattr_value_get API
>     * Added eina_inarray data type
> +    * Added eina_value data type (generic value storage)
>
>  Eina 1.1.0
>
>
> Modified: trunk/eina/src/include/Eina.h
> ===
> --- trunk/eina/src/include/Eina.h       2012-01-11 02:06:07 UTC (rev 67034)
> +++ trunk/eina/src/include/Eina.h       2012-01-11 02:20:26 UTC (rev 67035)
> @@ -188,6 +188,7 @@
>  #include "eina_refcount.h"
>  #include "eina_mmap.h"
>  #include "eina_xattr.h"
> +#include "eina_value.h"
>
>  #ifdef __cplusplus
>  }
>
> Modified: trunk/eina/src/include/Makefile.am
> ===
> --- trunk/eina/src/include/Makefile.am  2012-01-11 02:06:07 UTC (rev 67034)
> +++ trunk/eina/src/include/Makefile.am  2012-01-11 02:20:26 UTC (rev 67035)
> @@ -62,7 +62,9 @@
>  eina_prefix.h \
>  eina_refcount.h \
>  eina_mmap.h \
> -eina_xattr.h
> +eina_xattr.h \
> +eina_value.h \
> +eina_inline_value.x
>
>  # Will be back for developper after 1.1.
>  # eina_object.h
>
> Modified: trunk/eina/src/include/eina_inarray.h
> ===
> --- trunk/eina/src/include/eina_inarray.h       2012-01-11 02:06:07 UTC (rev 
> 67034)
> +++ trunk/eina/src/include/eina_inarray.h       2012-01-11 02:20:26 UTC (rev 
> 67035)
> @@ -272,6 +272,26 @@
>                                       const void *data) EINA_ARG_NONNULL(1, 
> 3);
>
>  /**
> + * @brief Copy the data over the given position.
> + * @param array array object
> + * @param position where to replace the member
> + * @param data data to be copied at position
> + * @return #EINA_TRUE on success, #EINA_FALSE on failure.
> + *
> + * Copies the given pointer contents at the given @a position in the
> + * array. The pointer is not referenced, instead it's contents is
> + * copied to the members array using the previously defined
> + * @c member_size.
> + *
> + * If @a position does not exist, it will fail.
> + *
> + * @since 1.2
> + */
> +EAPI Eina_Bool eina_inarray_replace_at(Eina_Inarray *array,
> +                                       unsigned int position,
> +                                       const void *data) EINA_ARG_NONNULL(1, 
> 3);
> +
> +/**
>  * @brief Remove member at given position
>  * @param array array object
>  * @param position position to be removed
>
> Modified: trunk/eina/src/lib/eina_inarray.c
> ===
> --- trunk/eina/src/lib/eina_inarray.c

Re: [E-devel] Genlist relative insertion bugs

[Daniel Juyung Seo]

On Sat, Jan 7, 2012 at 11:22 AM, Gustavo Sverzut Barbieri
 wrote:
> Hi guys,
>
> Doing some simple changes to enjoy resulted in lots of bugs with
> genlist... who is using it for more than a simple demo? Seems totally
> unusable for real work usage :-(
>
> Aside from previous bug that have genlist to get double-events while
> in naviframe and you unselect the genlist item from the selected
> callback, now I have a nasty one: relative insertion is totally broken
> except for the simple toplevel case!
>
> The list inserted sort is completely broken as well. I thought about
> rewriting it to use relative inserting, but bingo... it was broken :-(

Thanks for the report.

> Then both tests were added to elementary so people can fix it.

How can I reproduce the bug from that elm test? While running "Genlist
Tree, Insert Relative" and "Genlist Tree. Insert Sorted", I didn't
find a problem :(

Daniel Juyung Seo (SeoZ)


>
> The code is a mess and should reuse more, to avoid bugs in the future.
> Inserted sort should rely on relative insertion, avoiding such strange
> behavior :-/
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Genlist relative insertion bugs

[Daniel Juyung Seo]

On Sat, Jan 7, 2012 at 9:34 PM, Cedric BAIL  wrote:
> Hey,
>
> On Sat, Jan 7, 2012 at 3:22 AM, Gustavo Sverzut Barbieri
>  wrote:
>> Doing some simple changes to enjoy resulted in lots of bugs with
>> genlist... who is using it for more than a simple demo? Seems totally
>> unusable for real work usage :-(
>>
>> Aside from previous bug that have genlist to get double-events while
>> in naviframe and you unselect the genlist item from the selected
>> callback, now I have a nasty one: relative insertion is totally broken
>> except for the simple toplevel case!
>>
>> The list inserted sort is completely broken as well. I thought about
>> rewriting it to use relative inserting, but bingo... it was broken :-(
>> Then both tests were added to elementary so people can fix it.
>>
>> The code is a mess and should reuse more, to avoid bugs in the future.
>> Inserted sort should rely on relative insertion, avoiding such strange
>> behavior :-/
>
> As both relative and sorted insert use almost the same code, that
> doesn't surprise me much. The only tested use case with sorted insert

Hello,

> is the filemanager, so very simple case. I have no doubt that group
> support is broken.

Group support is broken? Can you describe it more?

Daniel Juyung Seo (SeoZ)

> --
> Cedric BAIL
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina: . src/include src/lib src/tests

[Michael Blumenkrantz]

On Tue, 10 Jan 2012 18:20:26 -0800
"Enlightenment SVN"  wrote:

> Log:
> add eina_value.
>   
>   eina value is a generic value storage, it's quite efficient to space
>   (16 bytes) and speed (inlines for basic types).
>   
>   It's basically a structure describing how to manage memory
>   (Eina_Value_Type), with default implementation for char, short, int,
>   long, int64_t (and unsigned variants), float, double, stringshare and
>   string.
>   
>   If a type 'value_size' is smaller than 8 bytes, it's stored
>   inline. Otherwise a value is allocated and managed.
>   
>   Most of the methods are inline, with special handling for char, short,
>   int... Then no extra calls are made, allowing the compiler to optimize
>   them.
>   
>   For array of a single type it is recommend to use Eina_Value_Array, as
>   it will efficiently store and access members (just a char if subtype
>   is EINA_VALUE_TYPE_CHAR, etc).
>   
>   It can copy itself, compare itself. Including arrays.
>   
>   It would be nice to have something that converts between EET and this.
>   
>   
> 
> Author:   barbieri
> Date: 2012-01-10 18:20:26 -0800 (Tue, 10 Jan 2012)
> New Revision: 67035
> Trac: http://trac.enlightenment.org/e/changeset/67035
> 
> Added:
>   trunk/eina/src/include/eina_inline_value.x
> trunk/eina/src/include/eina_value.h trunk/eina/src/tests/eina_test_value.c
> Modified: trunk/eina/ChangeLog trunk/eina/NEWS trunk/eina/src/include/Eina.h
> trunk/eina/src/include/Makefile.am trunk/eina/src/include/eina_inarray.h
> trunk/eina/src/lib/eina_inarray.c trunk/eina/src/lib/eina_main.c
> trunk/eina/src/lib/eina_value.c trunk/eina/src/tests/Makefile.am
> trunk/eina/src/tests/eina_suite.c trunk/eina/src/tests/eina_suite.h 

this commit breaks the universe for c++. please fix it.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel