Page MenuHomePhabricator

Edje & evas: prevent some API calls when an object is swallowed
Open, WishlistPublic

Description

ORIGINAL TITLE: Crazy override

When an object is swallowed into edje, the user should not call visibility change, clip and a few set of API. To prevent error in application, it would be neat to be able to override this function when the object is swallowed. This way on edje recalc, the swallowed object would be unlocked and the normal call to resize, move, change color, visibility, clip and so on would go through. Otherwise they will generate an error and bail.

To do this, we would need to improve the performance of override and deduplicate overrided class as much as possible. It is a trick that every efl container could do to make sure that application do not do something crazy with the item they are given. This could be also an option turned on during the development cycle and disable on release maybe ? or something like that.

cedric added a comment.Apr 3 2017, 1:19 PM

We may be able to do without this, by just having a private function in evas that just edje would use to do the same work without an absurd amount of infrastructure work.

jpeg added a comment.Apr 18 2017, 7:02 PM
In T5332#84805, @cedric wrote:

We may be able to do without this, by just having a private function in evas that just edje would use to do the same work without an absurd amount of infrastructure work.

We have to do something simple & non invasive, if we do anything :)

jpeg renamed this task from Crazy override to Edje & evas: prevent some API calls when an object is swallowed.May 12 2017, 1:52 AM
jpeg updated the task description. (Show Details)
jpeg added a subscriber: barbieri.Jun 18 2017, 10:09 PM

@barbieri on the mailing list

coming late to the party, but one idea may be to implement the
limitations in another way, like a per-method control where the owner
object could prevent other objects or call sites to use that.

practically speaking we could set a random token on an object + method
and Eo would check that "on the stack" prior to method resolution.
Similar to the thread domain, we could have something like this:

// once, at setup
efl_method_ownership_take(obj, owner, a_method); // horrible name :-/
 
// calling taken method
efl_method_ownership_push(obj, owner);
a_method(obj);
efl_method_ownership_pop(obj); // or , owner to avoid mistakes...
 
// to allow everytone to call that method:
efl_method_ownership_release(obj, owner, a_method);

Then edje would take ownership of objects, at least for methods it
manages (visibility, color, clip, geometry...).

This could be investigated, but I fear a high cost in eo_call_resolve as well as in edje (unlock all functions, do stuff, relock). Maybe overkill for something that should really just be about debug.
Alternatively the feature could be used only with eo_debug, and the lock/unlock functions would be nop outside of eo_debug. (This would then prove useful only if we can push people to test their apps with eo_debug).

cedric lowered the priority of this task from TODO to Wishlist.Jul 10 2017, 3:21 PM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:58 AM
segfaultxavi edited projects, added efl: layout engine; removed Restricted Project.Jun 11 2018, 8:26 AM