Re: [E-devel] [PATCH] External parts in Edje
On Tue, Jun 30, 2009 at 11:06 PM, Brian Matternreph...@rephorm.com wrote: Hey everyone, I've attached a patch that implements a new edje part type: EXTERNAL. rephorm, sorry taking so long to reply but I was quite busy the last days. I hope you still have time to hack on it. First, feedback on patch: rename 'double' to 'float'? I guess in edje/embryo we call 'float', at least this is my impression. Now after think about it and gather some requisites with friends, I see that we should change the handling of parameters. The edc format is fine, but the registry part should provide more information so we can introspect and tools can provide more information to users, the bonus point is that we can do validation for external objects. External providers: If we use something like Eet_Data_Descriptors we could provide digested and validated memory blob to users, just like eet_data_read(). This would avoid everywhere to handle things with edje_external_param_int_get() and like. We could even use Eet_Data_Descriptors as is for that. Editing tools (edje_editor): We could list all registered types and provide users with easy to use extensions. Icons and parameter introspection come to mind: - Adding an icon is simple, I'd say Edje_External_Type could get icon_get() and label_get() callbacks, just like e17 gadcons. - Parameter introspection: with name and type from Eet_Data_Descriptor we can already present a rough UI, but if we extend it more we can provide tooltips and possibly more, like automatically checking enumerations. We can also use this to generate documentation as HTML. What do you think about it? My idea is to add these callbacks to Edje_External_Type, using concepts and descriptions from eet, e_gadcon and ecore_getopt. Aside from that, what would change is the add() function would get an extra parameter void *parsed_params This could be even made const void *parsed_params so we do not need to allocate/free memory after each call. Thanks, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] External parts in Edje
Brian Mattern wrote:
Hey everyone,
I've attached a patch that implements a new edje part type: EXTERNAL.
The basic idea is as follows:
An application (or library) can implement swallowable widgets that are
keyed by a type name. By implementing a few callbacks and registering
with edje, the app can allow a themer to include a part of this type
by simply doing:
part {
name: external_part;
type: EXTERNAL;
source: type_name;
description {
...
params { int: foo 10; string: bar str_val; ... }
}
}
The current callbacks are:
Evas_Object *add(void *data, Evas *e, Evas_Object *parent, const
Eina_List *params)
gets called when edje loads and finds an external part of this type
the parent object is passed in so that it can be sent signals/messages
void signal_emit(void *data, Evas_Object *obj, const char *emission,
const char *source)
probably should be called 'signal_recv' or so, but gets called when
a signal like 'external_part:signal_name' is sent to the parent edj
(like GROUP objects, the part name and colon gets stripped off).
void state_set(void *data, Evas_Object *obj, const Eina_List
*from_params, const Eina_List *to_params, float pos)
called whenever the state changes (including repeatedly while
tweening between states)
use pos to linearly interpolate params between states
I also attached a really basic test program (nothing fancy, left or
right click on the bg to trigger state changes or press 's' to switch
themes) to illustrate the usage.
It would be interesting to register all of elementary's widgets with
edje in this fashion. (We'd still need some way for the theme to
specify which app data should be associated with the widget).
Anyway, before committing this, I'd like to get some feedback on the
API and ideas for how to extend this concept.
Brian
Hey Brian :)
I think it could take some time for people to find and build ways
to use this creatively. It would be interesting to see some initial
attempts at that.
One 'simple' way to use it would be via custom smart classes that
do some things that evas currently can't directly do... eg. various
kinds of custom rendering.
Lots that could be done with just that, even some very complex
stuff like svg or html rendering or just some basic things like custom
kinds of thumbnail generation, borders or decoration effects, etc.
Such new custom objects could then be incorporated into an edje for
whatever reason an app/lib might want to use that for.. eg. one could
define new kinds of widgets (for ewl or etk or elem) which would use
such custom things as part of the widget's theme.
Or in a kind of converse to that, as you suggested, use existing elem
widgets as new external parts say to define some creative kinds of layout
mechanisms for compound types and use that in defining the notion of
'theme' for such a layout-oriented widget, or scene, or whatever else.
However, I'm not sure if it would 'replace' something like a separate
lib that could 'extend' edje say in that it would allow for a declarative
means to define eg. elementary widget types or other evas object types
and their particular properties more explicitly, along with possibly
inlined or referenced edje groups... ie. something like Hisham's evolve/edc,
or some such. That approach would likely seem more 'natural' to many
people as a means to add basic widgets into a declarative format.
As to the api.. seems fine to me, though I'm not sure why you feel
the 'add' constructor would benefit by having the 'data' argument?
As to possible extensions of the concept...
Research interior design degree programs offered by top schools. Click Here.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIfrbPAUteJeqRooR2UvY5RcbWYdmJiwNaVidvzSSLwCaMW5Q1BiI/
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] External parts in Edje
On Wed, Jul 1, 2009 at 4:06 AM, Brian Matternreph...@rephorm.com wrote:
Hey everyone,
I've attached a patch that implements a new edje part type: EXTERNAL.
The basic idea is as follows:
Oh ! That's sounds good !
An application (or library) can implement swallowable widgets that are keyed
by a type name. By implementing a few callbacks and registering with edje,
the app can allow a themer to include a part of this type by simply doing:
part {
name: external_part;
type: EXTERNAL;
source: type_name;
description {
...
params { int: foo 10; string: bar str_val; ... }
}
}
The current callbacks are:
Evas_Object *add(void *data, Evas *e, Evas_Object *parent, const Eina_List
*params)
gets called when edje loads and finds an external part of this type
the parent object is passed in so that it can be sent signals/messages
void signal_emit(void *data, Evas_Object *obj, const char *emission, const
char *source)
probably should be called 'signal_recv' or so, but gets called when a
signal like 'external_part:signal_name' is sent to the parent edj (like
GROUP objects, the part name and colon gets stripped off).
void state_set(void *data, Evas_Object *obj, const Eina_List *from_params,
const Eina_List *to_params, float pos)
called whenever the state changes (including repeatedly while tweening
between states)
use pos to linearly interpolate params between states
I also attached a really basic test program (nothing fancy, left or right
click on the bg to trigger state changes or press 's' to switch themes) to
illustrate the usage.
It would be interesting to register all of elementary's widgets with edje in
this fashion. (We'd still need some way for the theme to specify which app
data should be associated with the widget).
Regarding the association of app data to widget, currently we need to
request the object_part and send data to it. Do you/people consider it
would be really better to just transmit the data to edje and let it do
what ever the theme want with this data ? (Think with an improved
script support like lua in edje).
Anyway, before committing this, I'd like to get some feedback on the API and
ideas for how to extend this concept.
Just a small point regarding your patch. All the
edje_external_param_*_get return EINA_FALSE if ret == NULL, I would
prefer to return EINA_TRUE if the param is found. With that it will be
possible to just test the presence of param.
Anyway the rest of the patch is quite small and easy to understand.
Edje need it in my opinion, so I would really accept it as is in svn.
--
Cedric BAIL
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] External parts in Edje
Hey everyone,
I've attached a patch that implements a new edje part type: EXTERNAL.
The basic idea is as follows:
An application (or library) can implement swallowable widgets that are
keyed by a type name. By implementing a few callbacks and registering
with edje, the app can allow a themer to include a part of this type by
simply doing:
part {
name: external_part;
type: EXTERNAL;
source: type_name;
description {
...
params { int: foo 10; string: bar str_val; ... }
}
}
The current callbacks are:
Evas_Object *add(void *data, Evas *e, Evas_Object *parent, const
Eina_List *params)
gets called when edje loads and finds an external part of this type
the parent object is passed in so that it can be sent signals/messages
void signal_emit(void *data, Evas_Object *obj, const char *emission,
const char *source)
probably should be called 'signal_recv' or so, but gets called when
a signal like 'external_part:signal_name' is sent to the parent edj
(like GROUP objects, the part name and colon gets stripped off).
void state_set(void *data, Evas_Object *obj, const Eina_List
*from_params, const Eina_List *to_params, float pos)
called whenever the state changes (including repeatedly while
tweening between states)
use pos to linearly interpolate params between states
I also attached a really basic test program (nothing fancy, left or
right click on the bg to trigger state changes or press 's' to switch
themes) to illustrate the usage.
It would be interesting to register all of elementary's widgets with
edje in this fashion. (We'd still need some way for the theme to specify
which app data should be associated with the widget).
Anyway, before committing this, I'd like to get some feedback on the API
and ideas for how to extend this concept.
Brian
external_test.tar.gz
Description: application/gzip
diff --git a/src/bin/edje_cc_handlers.c b/src/bin/edje_cc_handlers.c
index c68a4e3..2ad00d2 100644
--- a/src/bin/edje_cc_handlers.c
+++ b/src/bin/edje_cc_handlers.c
@@ -129,6 +129,7 @@ static void st_collections_group_parts_part_box_items_item_options(void);
static void st_collections_group_parts_part_table_items_item_position(void);
static void st_collections_group_parts_part_table_items_item_span(void);
+
static void ob_collections_group_parts_part_description(void);
static void st_collections_group_parts_part_description_inherit(void);
static void st_collections_group_parts_part_description_state(void);
@@ -194,6 +195,11 @@ static void st_collections_group_parts_part_description_table_homogeneous(void);
static void st_collections_group_parts_part_description_table_align(void);
static void st_collections_group_parts_part_description_table_padding(void);
+/* external part parameters */
+static void st_collections_group_parts_part_description_params_int(void);
+static void st_collections_group_parts_part_description_params_double(void);
+static void st_collections_group_parts_part_description_params_string(void);
+
static void ob_collections_group_programs_program(void);
static void st_collections_group_programs_program_name(void);
static void st_collections_group_programs_program_signal(void);
@@ -391,6 +397,9 @@ New_Statement_Handler statement_handlers[] =
{collections.group.parts.part.description.table.homogeneous, st_collections_group_parts_part_description_table_homogeneous},
{collections.group.parts.part.description.table.align, st_collections_group_parts_part_description_table_align},
{collections.group.parts.part.description.table.padding, st_collections_group_parts_part_description_table_padding},
+ {collections.group.parts.part.description.params.int, st_collections_group_parts_part_description_params_int},
+ {collections.group.parts.part.description.params.double, st_collections_group_parts_part_description_params_double},
+ {collections.group.parts.part.description.params.string, st_collections_group_parts_part_description_params_string},
{collections.group.parts.part.description.images.image, st_images_image}, /* dup */
{collections.group.parts.part.description.font, st_fonts_font}, /* dup */
{collections.group.parts.part.description.fonts.font, st_fonts_font}, /* dup */
@@ -550,6 +559,7 @@ New_Object_Handler object_handlers[] =
{collections.group.parts.part.description.gradient.rel2, NULL},
{collections.group.parts.part.description.box, NULL},
{collections.group.parts.part.description.table, NULL},
+ {collections.group.parts.part.description.params, NULL},
{collections.group.parts.part.description.color_classes, NULL}, /* dup */
{collections.group.parts.part.description.color_classes.color_class, ob_color_class}, /* dup */
{collections.group.parts.part.description.program, ob_collections_group_programs_program}, /* dup */
@@ -1651,6 +1661,7 @@ st_collections_group_parts_part_type(void)
GROUP, EDJE_PART_TYPE_GROUP,
BOX,
