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. > 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). 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
