On Wed, Feb 15, 2017 at 11:49 PM, Cedric BAIL <[email protected]> wrote:
> On Wed, Feb 15, 2017 at 8:18 AM, Gustavo Sverzut Barbieri
> <[email protected]> wrote:
>> On Wed, Feb 15, 2017 at 1:47 PM, Amitesh Singh <[email protected]>
>> wrote:
>>> Hey guys,
>>>
>>> edje_object_part_swallow_get() used to return subgroup object in an
>>> edje till 1.16. It seems that the behavior is changed in current
>>> master.
>>>
>>> Was it intentional? or missed it during efl interfaces development?
>
> You should not access any internal part, only object you have
> swallowed, so yes, it feels like a bug was fixed in 1.16.
>
>> bit more of context:
>>
>> he asked in #edevelop how to retrieve the Edje object associated with
>> a part of type GROUP, which he need to feed some signals/events
>> directly.
>
> A GROUP could become something else in another theme, so you don't
> want to force the API of your theme to expose its internal structure.
> This is why you can send a signal to a GROUP directly by sending a
> signal to its parent (And that should work if nobody borked it). There
> has been mistake made during the development of edje, so by default,
> we now broadcast all signals/events to the child, which leads to
> confusion and problem. So first step is to disable the broadcast
> behavior in the edc with ' broadcast_signal: off'. Then you can send a
> signal to a specific group with the signal being set as :
> "groups:signal". The groups name can be an alias itself. Also you can
> emit this from an edje program directly which is recommended to
> completely hide the structure of the theme.
>
Thanks and i know that. Sorry, i did not explain my problem in detail.
I wanted to call edje_object_message_signal_process() on 3rd level
group since signal_process for this level group gets queued up.
theme was like below
group { name: "genlist_item_theme";
..
part { name: "group1"; type: GROUP;
source: "group1_theme";
}
..
}
group { name: "group1_theme";
..
part { name: "group2"; type: GROUP;
source: "group2_theme";
}
}
group { name: "group2_theme"; <-- contents item contents of genlist.
..
..
}
In this case, signals for group2_theme gets queued up. This kind of
design is done to optimize the map usage (for animation).
Due to this, the genlist item contents appear on left side for few ms
in case of RTL whenever genlist gets shown. :)
>> I recalled swallow_get did that, maybe on purpose, maybe just happened
>> to work since we used the same pointers internally.
>
> Yes, it was not meant to be working that way. swallow_get should only
> expose object that are given to it and no internal object.
>
>> Amitesh tested and spotted it was a regression... I'm pretty sure I've
>> used this in the past (otherwise I'd not remember about it), thus that
>> may be the case for others and I don't see why we should block that
>> behavior (call it a "bugfix" instead of a "regression") -- as he shows
>> the patch is pretty simple.
>
> As above, I think it is bad to expose internal structure of a theme
> (There is an entire part of the API of edje for doing that sadly, I
> know). It is even worse to do so via an API that is not symetric (You
> can't swallow an object to replace a GROUP part).
>
> Cedric
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
