From: I. B. (S. <sac...@gm...> - 2008-11-21 14:50:56
Attachments:
box.c
edje-box.patch
|
Hello list, Attached is a patch that adds the Evas box functionality to Edje, allowing to define a box in themes, which can contain objects added by applications or other groups. It supports all the layouts defined in Evas by default and it can register custom layouts which the theme can also reference. The layout_register function needs some explanation, there are two ways this can be done, one is the one used in this patch, a bit cumbersome, and a simpler one just using name, layout_func, data and free_data. The reason for this: The evas_box_layout_set function gets the function that defines the layout, a private data pointer and the function to free that data as parameters, and whenever another layout is set, that pointer is freed. >From Edje, this can be handled in the two ways mentioned above, being the differences that, for the simpler case, we could pass NULL to Evas as the free_data func, and free the data from Edje. Again, this case is simpler, but it keeps those pointers around for as long as the layout is registered. The current case, a bit more complicated, has two more functions, and the private data is kept in Edje, not passed directly to Evas. That one is retrieved with layout_data_get, which receives the private pointer kept in Edje, which in turn is freed by free_data when the layout is unregistered. The pointer from layout_data_get is freed by Evas with layout_data_free when another layout is set. It's not as straight forward as the other one, but it lets the application keep a small pointer around and allocate a bigger one only when necessary. Test at will, opinions are of course welcome, specially for the layout register. |
From: Cedric B. <ced...@fr...> - 2008-11-21 15:20:47
|
On Fri, Nov 21, 2008 at 3:50 PM, Iván Briano (Sachiel) <sac...@gm...> wrote: > Hello list, > Attached is a patch that adds the Evas box functionality to Edje, > allowing to define a box in themes, which can contain objects added > by applications or other groups. It supports all the layouts defined > in Evas by default and it can register custom layouts which the > theme can also reference. <snip> > Test at will, opinions are of course welcome, specially for the layout register. Just reading your patch, not tested yet. I have only one comment using hash for layout matching is not really a good option regarding memory consuption. It would be better to put them in a rbtree, it will do around 3 strcmp for all the current layout beeing fast enough without using too much memory. At the same time, you could setup a static array of Edje_Box_Layout with all default layout and initialize the rbtree from it (would make the code cleaner imho). Anyway, it's really a good think seeing this stuff coming in edje. -- Cedric BAIL |
From: I. B. (S. <sac...@gm...> - 2008-11-21 15:57:54
|
On Fri, Nov 21, 2008 at 1:20 PM, Cedric BAIL <ced...@fr...> wrote: > On Fri, Nov 21, 2008 at 3:50 PM, Iván Briano (Sachiel) > <sac...@gm...> wrote: >> Hello list, >> Attached is a patch that adds the Evas box functionality to Edje, >> allowing to define a box in themes, which can contain objects added >> by applications or other groups. It supports all the layouts defined >> in Evas by default and it can register custom layouts which the >> theme can also reference. > <snip> >> Test at will, opinions are of course welcome, specially for the layout register. > > Just reading your patch, not tested yet. I have only one comment using > hash for layout matching is not really a good option regarding memory > consuption. It would be better to put them in a rbtree, it will do > around 3 strcmp for all the current layout beeing fast enough without > using too much memory. At the same time, you could setup a static > array of Edje_Box_Layout with all default layout and initialize the > rbtree from it (would make the code cleaner imho). > Truth be told, I just checked in Eina the names of functions for things I already knew. I will look at the other stuff and follow your suggestion. The static array is a good idea, I wanted to avoid the mess in init, but that one didn't occurred to me. > Anyway, it's really a good think seeing this stuff coming in edje. Table follows, stay tuned. > -- > Cedric BAIL > |
From: I. B. (S. <sac...@gm...> - 2008-11-21 16:20:38
Attachments:
box.edc
|
Sourceforge dropped the theme, here it is now. |
From: Gustavo S. B. <bar...@pr...> - 2008-11-21 19:28:20
Attachments:
edje-box_v2.patch
|
On Fri, Nov 21, 2008 at 12:50 PM, Iván Briano (Sachiel) <sac...@gm...> wrote: > Hello list, > Attached is a patch that adds the Evas box functionality to Edje, > allowing to define a box in themes, which can contain objects added > by applications or other groups. It supports all the layouts defined > in Evas by default and it can register custom layouts which the > theme can also reference. > > The layout_register function needs some explanation, there are two > ways this can be done, one is the one used in this patch, a bit cumbersome, > and a simpler one just using name, layout_func, data and free_data. > The reason for this: > The evas_box_layout_set function gets the function that defines the layout, > a private data pointer and the function to free that data as parameters, > and whenever another layout is set, that pointer is freed. > >From Edje, this can be handled in the two ways mentioned above, > being the differences that, for the simpler case, we could pass NULL > to Evas as the free_data func, and free the data from Edje. Again, this > case is simpler, but it keeps those pointers around for as long as the > layout is registered. > The current case, a bit more complicated, has two more functions, and > the private data is kept in Edje, not passed directly to Evas. That one is > retrieved with layout_data_get, which receives the private pointer kept > in Edje, which in turn is freed by free_data when the layout is unregistered. > The pointer from layout_data_get is freed by Evas with layout_data_free > when another layout is set. It's not as straight forward as the other one, > but it lets the application keep a small pointer around and allocate a > bigger one only when necessary. > > Test at will, opinions are of course welcome, specially for the layout register. after cedric complained about hash usage (it allocate a large array for buckets) and suggested moving to rbtree, I hacked the following. since most common use case is to have no custom layouts, being the built ins the most used, I opted to save at initalization time and have builtins split in their own, using a quick access search for them (works like a hash). It will save memory, keep fast and save some cycles on startup. Drawback is to keep builtins sorted and keep indexes consistent in builtin_find(), but it should not change that often and I added a comment. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2008-11-21 19:40:16
Attachments:
edje-box_v3.patch
|
On Fri, Nov 21, 2008 at 5:28 PM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Fri, Nov 21, 2008 at 12:50 PM, Iván Briano (Sachiel) > <sac...@gm...> wrote: >> Hello list, >> Attached is a patch that adds the Evas box functionality to Edje, >> allowing to define a box in themes, which can contain objects added >> by applications or other groups. It supports all the layouts defined >> in Evas by default and it can register custom layouts which the >> theme can also reference. >> >> The layout_register function needs some explanation, there are two >> ways this can be done, one is the one used in this patch, a bit cumbersome, >> and a simpler one just using name, layout_func, data and free_data. >> The reason for this: >> The evas_box_layout_set function gets the function that defines the layout, >> a private data pointer and the function to free that data as parameters, >> and whenever another layout is set, that pointer is freed. >> >From Edje, this can be handled in the two ways mentioned above, >> being the differences that, for the simpler case, we could pass NULL >> to Evas as the free_data func, and free the data from Edje. Again, this >> case is simpler, but it keeps those pointers around for as long as the >> layout is registered. >> The current case, a bit more complicated, has two more functions, and >> the private data is kept in Edje, not passed directly to Evas. That one is >> retrieved with layout_data_get, which receives the private pointer kept >> in Edje, which in turn is freed by free_data when the layout is unregistered. >> The pointer from layout_data_get is freed by Evas with layout_data_free >> when another layout is set. It's not as straight forward as the other one, >> but it lets the application keep a small pointer around and allocate a >> bigger one only when necessary. >> >> Test at will, opinions are of course welcome, specially for the layout register. > > after cedric complained about hash usage (it allocate a large array > for buckets) and suggested moving to rbtree, I hacked the following. > > since most common use case is to have no custom layouts, being the > built ins the most used, I opted to save at initalization time and > have builtins split in their own, using a quick access search for them > (works like a hash). It will save memory, keep fast and save some > cycles on startup. Drawback is to keep builtins sorted and keep > indexes consistent in builtin_find(), but it should not change that > often and I added a comment. new version with the registry being static in edje_util.c and Edje_Box_Layout structure being private to that file as well. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: I. B. (S. <sac...@gm...> - 2008-11-23 05:07:49
Attachments:
edje-box_v4.patch
|
On Fri, Nov 21, 2008 at 5:40 PM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Fri, Nov 21, 2008 at 5:28 PM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: >> On Fri, Nov 21, 2008 at 12:50 PM, Iván Briano (Sachiel) >> <sac...@gm...> wrote: >>> Hello list, >>> Attached is a patch that adds the Evas box functionality to Edje, >>> allowing to define a box in themes, which can contain objects added >>> by applications or other groups. It supports all the layouts defined >>> in Evas by default and it can register custom layouts which the >>> theme can also reference. >>> >>> The layout_register function needs some explanation, there are two >>> ways this can be done, one is the one used in this patch, a bit cumbersome, >>> and a simpler one just using name, layout_func, data and free_data. >>> The reason for this: >>> The evas_box_layout_set function gets the function that defines the layout, >>> a private data pointer and the function to free that data as parameters, >>> and whenever another layout is set, that pointer is freed. >>> >From Edje, this can be handled in the two ways mentioned above, >>> being the differences that, for the simpler case, we could pass NULL >>> to Evas as the free_data func, and free the data from Edje. Again, this >>> case is simpler, but it keeps those pointers around for as long as the >>> layout is registered. >>> The current case, a bit more complicated, has two more functions, and >>> the private data is kept in Edje, not passed directly to Evas. That one is >>> retrieved with layout_data_get, which receives the private pointer kept >>> in Edje, which in turn is freed by free_data when the layout is unregistered. >>> The pointer from layout_data_get is freed by Evas with layout_data_free >>> when another layout is set. It's not as straight forward as the other one, >>> but it lets the application keep a small pointer around and allocate a >>> bigger one only when necessary. >>> >>> Test at will, opinions are of course welcome, specially for the layout register. >> >> after cedric complained about hash usage (it allocate a large array >> for buckets) and suggested moving to rbtree, I hacked the following. >> >> since most common use case is to have no custom layouts, being the >> built ins the most used, I opted to save at initalization time and >> have builtins split in their own, using a quick access search for them >> (works like a hash). It will save memory, keep fast and save some >> cycles on startup. Drawback is to keep builtins sorted and keep >> indexes consistent in builtin_find(), but it should not change that >> often and I added a comment. > > new version with the registry being static in edje_util.c and > Edje_Box_Layout structure being private to that file as well. > New version with the new box_remove_all function. It won't remove internal objects defined from the theme though. Also, on compile it checks that box items have a source defined. > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > |