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 :-)
--
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
