2010/7/18 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>:
> On Sat, Jul 17, 2010 at 8:08 AM, Atton Jonathan
> <jonathan.at...@gmail.com> wrote:
>> Hello,
>>
>> I am writting this messages to give a list of what is needed in edje
>> external. I am rewriting the layout of enki and I see some limitations.
>>
>>
>> - We can't access to the content of a elementary widget (the content of
>> elm_notify for example). With a evas box we can use "box[item_name]", we
>> need the same tips with a external widget "notify[content]" or
>> "panes["left"].
>
> As said at IRC, this is a problem harder to solve in Elementary than
> in Edje/Externals API. We could just add a sub_object_get(name) to the
> externals API, but we have no standard way to get them from
> Elementary. If we need to implement it per-widget, it will be a major
> pain to keep in sync.
>
>
>> - a program which is in a group can't access to a sub-group. Simple
>> example : I have a part in a item of a box, a program can't have this item
>> as target "target:box[item]:part". If my program send a signal which should
>> set the state of this rectangle, I can't :(
>
> I recall Cedric and Sachiel doing something related to it these days.
> It should work with box and table at least.
>
>
>> - We can set the target of a elementary widget. For example, I have a
>> hoversel, I can't set his target. I have patched the hoversel, now the
>> default target is the edje group but we can't set a part as target.
>
> Again, this is highly specific of the Elementary's EXTERNAL
> implementation. You could do this today by exposing a property target
> with a string property that internally retrieves the object by name
> and calls the C function with it.
>
>
>> - Currently a program can't listen a smart event from a elementary
>> object. For example I can't have a program which listen the signal
>> "clicked"
>> of a elementary button.
>
> Well, it should be possible! Isn't it working? I did the initial
> implementation in external_signals_proxy(). It will use the
> introspection to listen to widget signals and proxy them to Edje, most
> of the objects exposed already have that, but if some are missing you
> can extend them just grep for Evas_Smart_Cb_Description in src/lib/,
> usually you find some code like elm_button.c:
>
> static const Evas_Smart_Cb_Description _signals[] = {
> {SIG_CLICKED, ""},
> {SIG_REPEATED, ""},
> {SIG_UNPRESSED, ""},
> {NULL, NULL}
> };
>
> ...
>
> evas_object_smart_callbacks_descriptions_set(obj, _signals);
>
>
> If the part that contains the button is called "bt" you should receive
> a "bt" "clicked" signal in Edje.
>
>
>> - we need generic interface for list/genlist/hoversel ... then in the
>> theme we can use other widegts (a list instead of a hoversel ...). This
>> part
>> is a big job.
>
> The sub-object management is not there, the problem is to define how
> to interact with it without being too specific to some lib. For
> instance, should we handle sub_object_get(name) (as above) and
> sub_object_set(name, value), choosing inside name if we want to
> append, prepend, insert or replace? Or should we create an extensive
> API, with replication in Embryo and Lua and probably
> edje_object_part_external with all possible sub-object management like
> append/prepend/insert/remove/replace? Of course we have
> middle-ground, with set, insert with key values such as -1 for end,
> remove... without replace/append/prepend variants.
>
> Anyway, the api is easy to extend, however if we're doing it, better
> do it sooner than later.
>
> But I'd like to see some real world use cases. In real world use
> cases, one often populate things like boxes from C... often those uses
> that you try to use them from Edje are wrong-usage, which you should
> just have many parts in the same object, or use Edje's native
> BOX/TABLE objects, or going even further, if you want your app to
> provide specific hoversel to some items, you create your specialized
> hoversel EXTERNAL in your app, register it to be used by Edje and have
> fun.
>
> One of the bad points of abusing these interfaces is that in a way or
> another, these are slower than plain C access. If you have to populate
> a huge genlist, for instance, for each item you'd have to call a
> function, resolve some text->object, then resolve text->function, then
> do some strcmp(), then call the final function.... but if you just get
> your edje_object_part_external_object_get(), you have the maximum
> speed, with all the required interface, checks and clear API usage.
>
> IOW, I don't want to introduce some option of bad habits just to make
> some demos simpler :-)
>
I totally agree with your position :)
We need to NOT abuse edje, edje files should just describe your interface,
don't make themes 'another program'
DaveMDS
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
