Re: [E-devel] How to add elements to an external Elm List widget?

[Iván B. (S. <sac...@gm...>]

On Tue, Oct 12, 2010 at 5:58 PM, Andreas Volz <li...@br...> wrote:
> Am Tue, 12 Oct 2010 09:49:58 -0300 schrieb Iván Briano (Sachiel):
>
>> >  // -> this doesn't change the List! Why?
>> >  ext_eo = edje_object_part_external_object_get (eo, "List01");
>> >  assert (elm_list_item_append (ext_eo, "1. Line", NULL, NULL, NULL,
>> >  NULL)); assert (elm_list_item_append (ext_eo, "2. Line", NULL,
>> > NULL, NULL, NULL)); assert (elm_list_item_append (ext_eo, "3.
>> > Line", NULL, NULL, NULL, NULL)); assert (elm_list_item_append
>> > (ext_eo, "4. Line", NULL, NULL, NULL, NULL));
>> >
>>
>> elm_list needs elm_list_go() after changing its items, or it won't
>> update anything.
>
> Ah, great. Now it works.
>
>> > " Almost all swallow rules apply: you should not move, resize, hide,
>> > show, set the color or clipper of such part. It's a bit more
>> > restrictive as one must never delete this object!"
>> >
>> > The result is a Evas_Object pointer. So what happens if someone
>> > calls it? Simply nothing and it doesn't hurt? Is it possible to get
>> > an error if someone calls the functions in a part? I ask this
>> > because I like to typesafe wrap this in C++. So I could decide
>> > between ignoring, throwing an Exception or creating derived objects
>> > with some less modifier functions to let the user not call these
>> > funtions.
>> >
>>
>> GROUP parts are like SWALLOW that automatically create an Edje object
>> with the given group and put it in there. EXTERNAL parts are the
>> same, except they create the widget using the externals framework.
>> After that, Edje handles its geometry and visibility, so you should
>> not touch that. In genernal, you never
>> mess with any property from anything created in Edje, but externals
>> are special in that they may have a ton of things they can do, of
>> which Edje knows nothing. So, for that, you must get the object with
>> that function and play with it as if you
>> had created, but always taking into consideration the restrictions
>> mentioned above.
>> With that said, call that function on a non EXTERNAL part, and you
>> should get NULL from it. How that works for you on the C++ bindings I
>> don't know.
>
> Hm, ok. Maybe my question wasn't clear enough. I mean I tried e.g. to
> to a evas_object_hide() on a EXTERNAL part. That seems to do nothing.
>
> So is this a behaviour I could rely on? It's no problem if I document
> this fact in the API docs. I only like to ensure that nothing bad
> happens if someone calls hide() on an EXTERNAL part. If this is "bad"
> in any way I would forbid it by having special ExternalPart objects for
> each type that simply provides no EXTERNAL "forbidden" functions.
>

Depends on the point of view. Mine comes now.
Since Edje handles visibility of its objects... all of them, calling show or
hide on those objects is not bad, but stupid. Don't do it.
Same goes for move(), resize(), color_set()... you get the idea, I hope.

In short (again), you never mess with any property of any internal object
you get from Edje. The reason external_object_get() doesn't return a
const Evas_Object *, is because you may want to do things Edje has no
control off, like adding elements to a list. But if you want to show or hide
that list, you do it the same way you do for any other rectangle defined
in the theme: send a signal to the object and handle it in there with programs
and different states.

> regards
>        Andreas
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>