[EMAIL PROTECTED] ha scritto:
>       I wrote:
>
>   
>>      Things like edje-editor and evolve could've been much further
>> along if these kinds of issues weren't there.. and it's where having
>> used already existing tools for 'edje' could've helped.
>>      One could have other formats/scripts as inputs to create
>> eet-encoded .edj files (I believe Tilman's "redact" is somewhat
>> like that), but it still leaves needing an api for the edje lib
>> to dynamically create/modify edje objects, to query properties,
>> determine structure, dependencies, etc.
>>     
>
>       Just to add another bit to that..
>
>       One 'problem' with an edje api for getting/setting properties
> is that it exposes edje's internal structure more and more.. which
> may or may not be desirable.
>   
The api I have in mind don't have this exposure problem:
I don't want to return pointer to the internal structs,
but only the asked value:

EAPI unsigned char edje_edit_part_type_get             (Evas_Object *obj, const 
char *part);
EAPI double        edje_edit_state_rel1_relative_x_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);

You ask edje what properties an object have and it return that value, 
the same for the various set functions.
In my idea all the functions take the name (string) of the part/state
and not the pointer to the internal struct.

>       Another way would also be to have a function like the current
> 'file_set' one, but which would allow one to set raw eet binary data.
>       Then, different apps/libs could use different formats/syntax/
> whatever to work with and just convert this to eet binary.. feeding
> that to the edje in order to create/modify it. It would be up to the
> app/lib to keep all relevant state rather than getting/setting such
> via edje lib calls.
>       However, in order to modify edje objs loaded from existing
> edje files, it would help to have available an eet-binary read/write
> lib that could do the querying of stuff.. and that would bring things
> back to a good api for that.
>       There are also some caching related issues, especially if
> you start trying to deal with image sources and such, and other stuff,
> that could come up here.
>
>    jose.
>   
I have never looked at eet... but this raise to me
a question:
after the edje has been modified in memory, how can I save it back to the
edje/eet file?
> _____________________________________________________________
> Click now and choose from a selection of top performing bonds!
> http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m5XftFiNIajJGI0DiwHsSnaqHaYAnF8fkJ5bkoeyFO4myAg/
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>   

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to