efl/legacy/edje/src/lib/edje_cache.c

631 lines
14 KiB
C
Raw Normal View History

/*
* vim:ts=8:sw=3:sts=8:noexpandtab:cino=>5n-3f0^-2{2
*/
/* EDJE - EFL graphical design and layout library based on Evas
* Copyright (C) 2008 Cedric Bail
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library;
* if not, see <http://www.gnu.org/licenses/>.
*/
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
#elif defined __GNUC__
# define alloca __builtin_alloca
#elif defined _AIX
# define alloca __alloca
#elif defined _MSC_VER
# include <malloc.h>
# define alloca _alloca
#else
# include <stddef.h>
# ifdef __cplusplus
extern "C"
# endif
void *alloca (size_t);
#endif
#include <string.h>
#include <sys/stat.h>
#include "edje_private.h"
/**
* @cond
*/
static Eina_Hash *_edje_file_hash = NULL;
static int _edje_file_cache_size = 16;
static Eina_List *_edje_file_cache = NULL;
static int _edje_collection_cache_size = 16;
static Edje_Part_Collection *
_edje_file_coll_open(Edje_File *edf, const char *coll)
{
Edje_Part_Collection *edc = NULL;
Edje_Part_Collection_Directory_Entry *ce;
Eina_List *l = NULL;
int id = -1, size = 0;
char buf[256];
void *data;
EINA_LIST_FOREACH(edf->collection_dir->entries, l, ce)
{
if ((ce->entry) && (!strcmp(ce->entry, coll)))
{
id = ce->id;
break;
}
}
if (id < 0) return NULL;
snprintf(buf, sizeof(buf), "collections/%i", id);
edc = eet_data_read(edf->ef, _edje_edd_edje_part_collection, buf);
if (!edc) return NULL;
snprintf(buf, sizeof(buf), "scripts/%i", id);
data = eet_read(edf->ef, buf, &size);
if (data)
{
edc->script = embryo_program_new(data, size);
free(data);
}
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
snprintf(buf, sizeof(buf), "lua_scripts/%i", id);
data = eet_read(edf->ef, buf, &size);
if (data)
{
int err_code;
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
//printf("lua chunk size: %d\n", size);
edc->L = _edje_lua_new_thread(_edje_lua_state_get()); // gets freed in 'edje_load::_edje_collection_free'
_edje_lua_new_reg(edc->L, -1, edc); // gets freed in 'edje_load::_edje_collectoin_free'
if ((err_code = luaL_loadbuffer(edc->L, data, size, "edje_lua_script")))
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
{
if (err_code == LUA_ERRSYNTAX)
ERR("lua load syntax error: %s", lua_tostring(edc->L, -1));
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
else if (err_code == LUA_ERRMEM)
ERR("lua load memory allocation error: %s", lua_tostring(edc->L, -1));
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
}
if (lua_pcall(edc->L, 0, 0, 0))
ERR("lua call error: %s", lua_tostring(edc->L, -1));
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
free(data);
}
edc->part = eina_stringshare_add(coll);
edc->references = 1;
if (!edf->collection_hash)
edf->collection_hash = eina_hash_string_small_new(NULL);
eina_hash_add(edf->collection_hash, coll, edc);
return edc;
}
2007-04-04 06:25:55 -07:00
static int
_edje_font_hash(Edje_File *edf)
2007-04-04 06:25:55 -07:00
{
int count = 0;
if (!edf->font_hash)
edf->font_hash = eina_hash_string_small_new(NULL);
2007-04-04 06:25:55 -07:00
if (edf->font_dir)
{
Eina_List *l;
Edje_Font_Directory_Entry *fnt;
EINA_LIST_FOREACH(edf->font_dir->entries, l, fnt)
2007-04-04 06:25:55 -07:00
{
int length;
char *tmp;
2007-04-04 06:25:55 -07:00
length = strlen(fnt->entry) + 7;
tmp = alloca(length);
snprintf(tmp, length, "fonts/%s", fnt->entry);
fnt->path = eina_stringshare_add(tmp);
if (edf->free_strings)
eina_stringshare_del(fnt->entry);
2007-04-04 06:25:55 -07:00
fnt->entry = fnt->path + 6;
eina_hash_direct_add(edf->font_hash, fnt->entry, fnt);
2007-04-04 06:25:55 -07:00
count++;
}
}
return count;
}
static Edje_File *
_edje_file_open(const char *file, const char *coll, int *error_ret, Edje_Part_Collection **edc_ret)
{
Edje_File *edf;
Edje_Part_Collection *edc;
Edje_Data *di;
Eet_File *ef;
Eina_List *l;
struct stat st;
if (stat(file, &st) != 0)
{
*error_ret = EDJE_LOAD_ERROR_DOES_NOT_EXIST;
return NULL;
}
ef = eet_open(file, EET_FILE_MODE_READ);
if (!ef)
{
*error_ret = EDJE_LOAD_ERROR_UNKNOWN_FORMAT;
return NULL;
}
edf = eet_data_read(ef, _edje_edd_edje_file, "edje_file");
if (!edf)
{
*error_ret = EDJE_LOAD_ERROR_CORRUPT_FILE;
eet_close(ef);
return NULL;
}
edf->free_strings = eet_dictionary_get(ef) ? 0 : 1;
edf->ef = ef;
if (edf->version != EDJE_FILE_VERSION)
{
*error_ret = EDJE_LOAD_ERROR_INCOMPATIBLE_FILE;
_edje_file_free(edf);
return NULL;
}
if (!edf->collection_dir)
{
*error_ret = EDJE_LOAD_ERROR_CORRUPT_FILE;
_edje_file_free(edf);
return NULL;
}
edf->path = eina_stringshare_add(file);
edf->references = 1;
_edje_textblock_style_parse_and_fix(edf);
if (!edf->data_cache)
edf->data_cache = eina_hash_string_small_new(NULL);
EINA_LIST_FOREACH(edf->data, l, di)
eina_hash_add(edf->data_cache, di->key, di->value);
2007-04-04 06:25:55 -07:00
if (coll)
{
edc = _edje_file_coll_open(edf, coll);
2007-04-04 06:25:55 -07:00
if (!edc)
{
*error_ret = EDJE_LOAD_ERROR_UNKNOWN_COLLECTION;
}
if (edc_ret) *edc_ret = edc;
}
2007-04-04 06:25:55 -07:00
edf->font_hash = NULL;
_edje_font_hash(edf);
return edf;
}
Edje_File *
_edje_cache_file_coll_open(const char *file, const char *coll, int *error_ret, Edje_Part_Collection **edc_ret)
{
Edje_File *edf;
Eina_List *l, *hist;
Edje_Part_Collection *edc;
Edje_Part *ep;
if (!_edje_file_hash)
_edje_file_hash = eina_hash_string_small_new(NULL);
edf = eina_hash_find(_edje_file_hash, file);
if (edf)
{
edf->references++;
}
else
{
EINA_LIST_FOREACH(_edje_file_cache, l, edf)
{
if (!strcmp(edf->path, file))
{
edf->references = 1;
_edje_file_cache = eina_list_remove_list(_edje_file_cache, l);
eina_hash_add(_edje_file_hash, file, edf);
break;
}
edf = NULL;
}
}
if (!edf)
{
edf = _edje_file_open(file, coll, error_ret, edc_ret);
if (!edf) return NULL;
eina_hash_add(_edje_file_hash, file, edf);
return edf;
}
if (!coll) return edf;
if (!edf->collection_hash)
edf->collection_hash = eina_hash_string_small_new(NULL);
edc = eina_hash_find(edf->collection_hash, coll);
if (edc)
{
edc->references++;
}
else
{
EINA_LIST_FOREACH(edf->collection_cache, l, edc)
{
if (!strcmp(edc->part, coll))
{
edc->references = 1;
edf->collection_cache = eina_list_remove_list(edf->collection_cache, l);
eina_hash_add(edf->collection_hash, coll, edc);
break;
}
edc = NULL;
}
}
if (!edc)
{
edc = _edje_file_coll_open(edf, coll);
if (!edc)
{
*error_ret = EDJE_LOAD_ERROR_UNKNOWN_COLLECTION;
}
else
{
EINA_LIST_FOREACH(edc->parts, l, ep)
{
Edje_Part *ep2;
/* Register any color classes in this parts descriptions. */
hist = NULL;
hist = eina_list_append(hist, ep);
ep2 = ep;
while (ep2->dragable.confine_id >= 0)
{
ep2 = eina_list_nth(edc->parts, ep2->dragable.confine_id);
if (eina_list_data_find(hist, ep2))
{
ERR("confine_to loops. invalidating loop.");
ep2->dragable.confine_id = -1;
break;
}
hist = eina_list_append(hist, ep2);
}
eina_list_free(hist);
hist = NULL;
hist = eina_list_append(hist, ep);
ep2 = ep;
while (ep2->dragable.events_id >= 0)
{
Edje_Part* prev;
prev = ep2;
ep2 = eina_list_nth(edc->parts, ep2->dragable.events_id);
if (!ep2->dragable.x && !ep2->dragable.y)
{
prev->dragable.events_id = -1;
break;
}
if (eina_list_data_find(hist, ep2))
{
ERR("events_to loops. invalidating loop.");
ep2->dragable.events_id = -1;
break;
}
hist = eina_list_append(hist, ep2);
}
eina_list_free(hist);
hist = NULL;
hist = eina_list_append(hist, ep);
ep2 = ep;
while (ep2->clip_to_id >= 0)
{
ep2 = eina_list_nth(edc->parts, ep2->clip_to_id);
if (eina_list_data_find(hist, ep2))
{
ERR("clip_to loops. invalidating loop.");
ep2->clip_to_id = -1;
break;
}
hist = eina_list_append(hist, ep2);
}
eina_list_free(hist);
hist = NULL;
}
}
}
if (edc_ret) *edc_ret = edc;
if (eina_hash_population(edf->collection_hash) == 0)
{
eina_hash_free(edf->collection_hash);
edf->collection_hash = NULL;
}
return edf;
}
void
_edje_cache_coll_clean(Edje_File *edf)
{
int count;
count = eina_list_count(edf->collection_cache);
while ((edf->collection_cache) && (count > _edje_collection_cache_size))
{
Edje_Part_Collection *edc;
edc = eina_list_data_get(eina_list_last(edf->collection_cache));
edf->collection_cache = eina_list_remove_list(edf->collection_cache, eina_list_last(edf->collection_cache));
_edje_collection_free(edf, edc);
count = eina_list_count(edf->collection_cache);
}
}
2005-11-02 00:13:56 -08:00
void
_edje_cache_coll_flush(Edje_File *edf)
{
while (edf->collection_cache)
{
Edje_Part_Collection *edc;
edc = eina_list_data_get(eina_list_last(edf->collection_cache));
edf->collection_cache = eina_list_remove_list(edf->collection_cache, eina_list_last(edf->collection_cache));
2005-11-02 00:13:56 -08:00
_edje_collection_free(edf, edc);
}
}
void
_edje_cache_coll_unref(Edje_File *edf, Edje_Part_Collection *edc)
{
edc->references--;
if (edc->references != 0) return;
eina_hash_del(edf->collection_hash, edc->part, edc);
if (eina_hash_population(edf->collection_hash) == 0)
{
eina_hash_free(edf->collection_hash);
edf->collection_hash = NULL;
}
edf->collection_cache = eina_list_prepend(edf->collection_cache, edc);
_edje_cache_coll_clean(edf);
}
static void
_edje_cache_file_clean(void)
{
int count;
count = eina_list_count(_edje_file_cache);
while ((_edje_file_cache) && (count > _edje_file_cache_size))
{
Edje_File *edf;
edf = eina_list_data_get(eina_list_last(_edje_file_cache));
_edje_file_cache = eina_list_remove_list(_edje_file_cache, eina_list_last(_edje_file_cache));
_edje_file_free(edf);
count = eina_list_count(_edje_file_cache);
}
}
void
_edje_cache_file_unref(Edje_File *edf)
{
edf->references--;
if (edf->references != 0) return;
eina_hash_del(_edje_file_hash, edf->path, edf);
if (!eina_hash_population(_edje_file_hash))
{
eina_hash_free(_edje_file_hash);
_edje_file_hash = NULL;
}
_edje_file_cache = eina_list_prepend(_edje_file_cache, edf);
_edje_cache_file_clean();
}
void
_edje_file_cache_shutdown(void)
{
edje_file_cache_flush();
}
/**
* @endcond
*/
/*============================================================================*
* Global *
*============================================================================*/
/*============================================================================*
* API *
*============================================================================*/
/**
* @addtogroup Edje_cache_Group Cache
*
* @brief These functions provide an abstraction layer between the
* application code and the interface, while allowing extremely
* flexible dynamic layouts and animations.
*
* @{
*/
/**
* @brief Set the file cache size.
*
* @param count The file cache size in edje file units. Default is 16.
*
* This function sets the file cache size. Edje keeps this cache in
* order to prevent duplicates of edje file entries in memory. The
* file cache size can be retrieved with edje_file_cache_get().
*
* @see edje_file_cache_get()
* @see edje_file_cache_flush()
*
*/
2006-01-07 00:54:30 -08:00
EAPI void
edje_file_cache_set(int count)
{
if (count < 0) count = 0;
_edje_file_cache_size = count;
_edje_cache_file_clean();
}
/**
* @brief Return the file cache size.
*
* @return The file cache size in edje file units. Default is 16.
*
* This function returns the file cache size set by
* edje_file_cache_set().
*
* @see edje_file_cache_set()
* @see edje_file_cache_flush()
*
*/
2006-01-07 00:54:30 -08:00
EAPI int
edje_file_cache_get(void)
{
return _edje_file_cache_size;
}
/**
* @brief Clean the file cache.
*
* @return The file cache size.
*
* This function cleans the file cache entries, but keeps this cache's
* size to the last value set.
*
* @see edje_file_cache_set()
* @see edje_file_cache_get()
*
*/
2006-01-07 00:54:30 -08:00
EAPI void
edje_file_cache_flush(void)
{
int ps;
ps = _edje_file_cache_size;
_edje_file_cache_size = 0;
_edje_cache_file_clean();
_edje_file_cache_size = ps;
}
/**
* @brief Set the collection cache size.
*
* @param count The collection cache size, in edje object units. Default is 16.
*
* This function sets the collection cache size. Edje keeps this cache
* in order to prevent duplicates of edje {collection,group,part}
* entries in memory. The collection cache size can be retrieved with
* edje_collection_cache_get().
*
* @see edje_collection_cache_get()
* @see edje_collection_cache_flush()
*
*/
2006-01-07 00:54:30 -08:00
EAPI void
edje_collection_cache_set(int count)
{
Eina_List *l;
Edje_File *edf;
if (count < 0) count = 0;
_edje_collection_cache_size = count;
EINA_LIST_FOREACH(_edje_file_cache, l, edf)
_edje_cache_coll_clean(edf);
/* FIXME: freach in file hash too! */
}
/**
* @brief Return the collection cache size.
*
* @return The collection cache size, in edje object units. Default is 16.
*
* This function returns the collection cache size set by
* edje_collection_cache_set().
*
* @see edje_collection_cache_set()
* @see edje_collection_cache_flush()
*
*/
2006-01-07 00:54:30 -08:00
EAPI int
edje_collection_cache_get(void)
{
return _edje_collection_cache_size;
}
/**
* @brief Clean the collection cache.
*
* @return The collection cache size.
*
* This function cleans the collection cache, but keeps this cache's
* size to the last value set.
*
* @see edje_collection_cache_set()
* @see edje_collection_cache_get()
*
*/
2006-01-07 00:54:30 -08:00
EAPI void
edje_collection_cache_flush(void)
{
int ps;
Eina_List *l;
Edje_File *edf;
ps = _edje_collection_cache_size;
_edje_collection_cache_size = 0;
EINA_LIST_FOREACH(_edje_file_cache, l, edf)
_edje_cache_coll_flush(edf);
/* FIXME: freach in file hash too! */
_edje_collection_cache_size = ps;
}
/**
*
* @}
*/