Hi, On 16 February 2017 at 03:52, Amitesh Singh <[email protected]> wrote:
> 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. > "Fixed" most likely by accident. > >> 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). > With efl_part we could return a virtual object that allows a limited set of functions. The tricky job would be to know what's "safe" to expose, and then the implementation would be a bit tedious, but it's doable. Even the legacy API would work for the equivalent set of functions. -- Jean-Philippe André ------------------------------------------------------------------------------ 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
