2017-07-21 5:38 GMT+09:00 Cedric BAIL <[email protected]>: > Hi, > > On Sun, Jul 16, 2017 at 7:19 PM, Jean-Philippe André <[email protected]> > wrote: > > I spotted 3 new APIs in evas object: > > > > efl_canvas_object.eo.legacy.h, libevas.so.1.20.0 > > evas_object_pointer_coords_inside_get ( Efl_Canvas_Object* obj, int x, > int > > y ) > > evas_object_pointer_inside_by_device_get ( Efl_Canvas_Object const* obj, > > Efl_Input_Device* dev ) > > evas_object_pointer_inside_get ( Efl_Canvas_Object const* obj ) > > > > There is no need for both evas_object_pointer_inside_get() and > > evas_object_pointer_inside_by_device_get(), just use NULL as device. > > Well, the reasonning is that legacy API are not exposing the device, > so to keep things coherent, they are duplicated here. I guess we could > get rid of the duplication, it would be fine by me. >
That's right. This form is indeed consistent with other legacy APIs. > > evas_object_pointer_coords_inside_get() also has nothing to do with > > pointer, it's just comparing geometries. I wonder if we shouldn't instead > > explicitely expose the bounding box as a public API on all objects, and > > then let the app do the comparison. Why? Because it's not clear what > > "logically inside" (as per the doc) really means: what if the smart obj > is > > full of "holes" and the given point is inside one of those holes? Then > the > > API would return true, even though it could be considered not "logically > > inside". > > I am not a fan of exposing the bounding box as the logic behind it is > not really related to the object size (If you have a smart object that > has children getting out of it, they would increase the bounding box, > but if you are using map, they wouldn't) and could get confusing. > Anyway. I see your point here, and I see why it should get more > documentation at a minimum. Would that be good enough or do you really > prefer to expose the including limit of an object (which is what the > bounding box is really). > > Yeah the bounding box can get weird sometimes. In fact we can have issues with map & proxies. Example a proxy of an edje object may not have the proper geometry to reflect the full contents of the edje. See e81be3a664737dd5743552578e832656e9c5b87e which transformed a proxy into a full edje because of that limitation. Well, then let's keep those APIs as they are now. Thanks. -- 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
