Carsten Haitzler (The Rasterman) ha scritto:
> On Wed, 28 Nov 2007 08:08:56 +0100 Dave <[EMAIL PROTECTED]> babbled:
>
>
>> Hi all
>> I'm working hard on the edje_editor in the last day, and my opinion now
>> is that
>> engrave can't render as edje does, and probablly will never. As
>> reproducing the edje
>> calculation is really hard. and also stupid to do the same thing 2 times.
>>
>> So I started to play with edje to modify it directly.
>> The result is super !!
>> Now the editor can load perfectly the default theme, browse trought all
>> the part and state.
>> The display is now perfect as the edje is a real edje (also all the
>> script/program/signal stuff
>> work inside the editor). I can also change the position of the various
>> part from the spinner
>> or dragging the red and blue dot.
>>
>> Nothing more for now as this require some addition to the edje library
>> and first I want
>> to hear the voice of the mantiners:
>> This is the first stub I have done of the new api
>>
>> + EAPI Evas_List *edje_edit_parts_list_get (Evas_Object
>> *obj);
>> + EAPI Evas_List *edje_edit_part_states_get (Evas_Object
>> *obj, const char *part);
>> + EAPI unsigned char edje_edit_part_type_get (Evas_Object
>> *obj, const char *part);
>> + EAPI void edje_edit_part_real_coord_get (Evas_Object
>> *obj, const char *part, int *x, int *y, int *w, int *h);
>> +
>> + EAPI double edje_edit_state_rel1_relative_x_get(Evas_Object
>> *obj, const char *part, const char *state);
>> + EAPI double edje_edit_state_rel1_relative_y_get(Evas_Object
>> *obj, const char *part, const char *state);
>> + EAPI void edje_edit_state_rel1_relative_x_set(Evas_Object
>> *obj, const char *part, const char *state, double x);
>> + EAPI void edje_edit_state_rel1_relative_y_set(Evas_Object
>> *obj, const char *part, const char *state, double y);
>> +
>> + EAPI double edje_edit_state_rel2_relative_x_get(Evas_Object
>> *obj, const char *part, const char *state);
>> + EAPI double edje_edit_state_rel2_relative_y_get(Evas_Object
>> *obj, const char *part, const char *state);
>> + EAPI void edje_edit_state_rel2_relative_x_set(Evas_Object
>> *obj, const char *part, const char *state, double x);
>> + EAPI void edje_edit_state_rel2_relative_y_set(Evas_Object
>> *obj, const char *part, const char *state, double y);
>>
>>
>> I have filed a patch to bgzilla with this first implementation. bug#294
>>
>> If you want to try it simply patch edje and set
>> #define TEST_DIRECT_EDJE 1
>> in edje_editor/src/bin/main.h on line 15
>>
>> then open the editor with a file to open:
>> edje_editor /path.to/default.edj
>>
>> But remember that you can't do nothing more than the browsing and change
>> size (all the other stuff will segv!)
>>
>> Please let me know what do you think about.
>>
>
> hmmm ok- this opens a can of worms. there is a LOOOOOOOOT of stuff in edje
> that
> you will need to provide access too, add/del description states, all the other
> properties etc. perhaps this would make more sense with a more compact (though
> less efficient api like:
>
> EAPI int edje_edit_val_int_get(Evas_Object *obj, const char *item);
> EAPI void edje_edit_val_int_set(Evas_Object Obj, const char *item, int val);
>
> i.e.
>
> rel1_x = edje_edit_val_int_get(obj,
> "parts/part/my.part.name/description/default/0.0/rel1.offset.x");
>
> we will need to escape "/" in names of items. i.e.
> "parts/part/my\\/part\\/name/..."
>
Just tried...the first test I have done was done using this system but I
get
into trouble (better to say complexity) because of the different behavior of
the various values. For example about the different limit a value can have:
color range from 0 to 255, rel1.offset.x from -maxint to +maxint and
text.size
from 0 to +maxint. And also while seaching the object to set the value
to: can be
a program, a state, a part...
You will fall on a function so done
edje_edit_val_int_get(obj,"parts/part/my.part.name/description/default/0.0/rel1.offset.x");
{
switch(type_of_value_to_get)
case rel1.offset.x:
...do the stuff
case color:
...do the stuff
and so on...
}
that is not so different to
edje_edit_rel1_offset_x_get(obj,char* part, char *part)
{
...do the stuff
}
edje_edit_color_get(obj,char* part, char *part)
{
...do the stuff
}
I prefer to add 2 functions (usually get and set) every time edje
change, without have to touch the general code. I'm for making this
api as simple as possible.
> for example. this would allow for expansion over time with minimal api changes
> - edje will grow over time and get big. this might be the best way to go?
> since
> this api doesn't need to be speedy and realtime for runtime use (just for
> editing) i think this might be ok and simplify things. what do you think? (of
> course have one to get int, double, bool string etc.). then add calls to
> add/delete and list nodes at tree depths. i.e. edje_edit_node_add(obj,
> "parts/part/my.part.name/description/new_desc/0.0"); then u can set keys under
> that node. if it already exists an error can be returned, and setting a value
> under a nodes that doesn't exist can also be an error - add calls to list
> nodes
> (only useful at certain depths in the tree) etc.
>
> ?
>
>
This seems to be an unnecessary major complexity, both in the editor and
the
edit_api ... I have to parse the 'long' string first in edje and then
in the editor.
...
Instead I need some help about a way to save the modified edje? I didn't
know
well eet and for now I haven't find a way to rewrite to file :(
Can you give me some direction on this?
Thanks.
Dave
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
