I have a problem with signal. My edje re-send the signal in a panes :
program {
name: "show_map";
signal: "main_panel,map,show";
action: SIGNAL_EMIT "panes[right]:main_panel,map,show" "";
}
Elementary external retrieve it in the method :
void external_signal(void *data __UNUSED__, Evas_Object *obj
__UNUSED__, const char *signal, const char *source)
and print the signal : right]:main_panel,map,show"
Ok I can parse it and send the signal to the right content.
But now Edje can do the job, edje can retrieve the content and send the
signal. Do you think this method in edje/elm external is still necessary ?
Do you plan to do samething specific inside ? Can we remove this method and
do the job in edje ?
2010/7/29 Atton Jonathan <jonathan.at...@gmail.com>
> A patch to get the content of a elementary object from edje. I have
> implemented a new function: external_content_get() but maybe I should use
> external_param_get() ?
>
>
>
> 2010/7/25 Atton Jonathan <jonathan.at...@gmail.com>
>
> My idea is to have 1 edje group by window. The application create the
>> window, load the group and get the objects needed (buttons, list ...).
>> With this method in the theme you have a complete controls: you can use 5
>> panels or 2, display 3 list or 3 buttons to display one of the three list
>> ...
>>
>> With generic interface we will have a way to have a theme for bif screen
>> with a list and a second for small screen with a hoversel. But this part is
>> not my priority, this is a big job.
>>
>> This is what I try to do with Enki. Then I will write a theme for small
>> screen like phone.
>>
>> My first problem will be to retrieve the content of a elementary object.
>> The first object in the current enki theme is a elm_panels. I will add the
>> possibility to do this.
>>
>> 2010/7/19 Dave Andreoli <d...@gurumeditation.it>
>>
>> 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
>>> >
>>>
>>
>>
>>
>> --
>> Regards.
>>
>
>
>
> --
> Regards.
>
--
Regards.
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
