[E-devel] ABI/API checker results from abi-laboratory for 1.20 beta1

Discussion:

Stefan Schmidt

2017-07-07 14:40:46 UTC

Hello.

Andrey V. Ponomarenko from ABI Laboratory keeps up the great work of
running his tools on EFL on a regular basis.

For the upcoming 1.20 release he has reports for all changes between
1.19.1 and 1.20-beta1

https://abi-laboratory.pro/tracker/timeline/efl/
https://abi-laboratory.pro/tracker/objects_report/efl/1.19.1/1.20.0-beta1/report.html

Please have a look at your respective areas and things you changed on
this cycle.

I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover both.

regards
Stefan Schmidt

Andrew Williams

2017-07-07 15:32:03 UTC

Permalink

It looks like some eo change moved many Evas_Coord to int - is that correct
or did we miss something?

Andy

Post by Stefan Schmidt
Hello.
Andrey V. Ponomarenko from ABI Laboratory keeps up the great work of
running his tools on EFL on a regular basis.
For the upcoming 1.20 release he has reports for all changes between
1.19.1 and 1.20-beta1
https://abi-laboratory.pro/tracker/timeline/efl/
https://abi-laboratory.pro/tracker/objects_report/efl/1.19.1/1.20.0-beta1/report.html
Please have a look at your respective areas and things you changed on
this cycle.
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover both.
regards
Stefan Schmidt
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
http://andywilliams.me
http://ajwillia.ms

Jean-Philippe André

2017-07-10 02:55:44 UTC

Permalink

Hi,

Post by Andrew Williams
It looks like some eo change moved many Evas_Coord to int - is that correct
or did we miss something?

I changed that in commit af3cb1018584e3c403024b.
ABI wise this doesn't change anything at all.

Since the legacy APIs are automatically generated they also use int instead
of Evas_Coord now.

Hope that's not a problem?

Post by Andrew Williams
Andy

19.1/1.20.0-beta1/report.html

Post by Stefan Schmidt
Please have a look at your respective areas and things you changed on
this cycle.
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover

both.

Post by Stefan Schmidt
regards
Stefan Schmidt
------------------------------------------------------------

------------------

Post by Stefan Schmidt
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
http://andywilliams.me
http://ajwillia.ms
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Jean-Philippe André

Andrew Williams

2017-07-10 04:30:02 UTC

Permalink

I'm curious as to why we've gone from named types back to primitive - is
this just for C bindings?

Andy

Post by Andrew Williams
Hi,

Post by Andrew Williams
It looks like some eo change moved many Evas_Coord to int - is that

correct

Post by Andrew Williams
or did we miss something?

I changed that in commit af3cb1018584e3c403024b.
ABI wise this doesn't change anything at all.
Since the legacy APIs are automatically generated they also use int instead
of Evas_Coord now.
Hope that's not a problem?

Post by Andrew Williams
Andy

19.1/1.20.0-beta1/report.html

both.

Post by Stefan Schmidt
regards
Stefan Schmidt
------------------------------------------------------------

------------------

--
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
http://andywilliams.me
http://ajwillia.ms

Carsten Haitzler (The Rasterman)

2017-07-10 05:27:05 UTC

Permalink

Post by Andrew Williams
I'm curious as to why we've gone from named types back to primitive - is
this just for C bindings?

Evas_Coord was used because initially evas had a compile option to have doubles
for coords instead of int's. i chose to stick with ints for performance on arm
(which had no fpu at the time)... and so eventually it just became infeasible
to have different abi's based on typedefed types in headers... so it was always
an int... so there is actually no value in Evas_Coord because changing it is
basically not feasible.

so i really see no value in keeping it :) it certainly is not useful for js or
lua where its just a number anyway... and will remain as such. :)

Post by Andrew Williams
Andy

Post by Andrew Williams
Hi,

Post by Andrew Williams
It looks like some eo change moved many Evas_Coord to int - is that

correct

Post by Andrew Williams
or did we miss something?

I changed that in commit af3cb1018584e3c403024b.
ABI wise this doesn't change anything at all.
Since the legacy APIs are automatically generated they also use int instead
of Evas_Coord now.
Hope that's not a problem?

Post by Andrew Williams
Andy

19.1/1.20.0-beta1/report.html

both.

Post by Stefan Schmidt
regards
Stefan Schmidt
------------------------------------------------------------

------------------

--
http://andywilliams.me
http://ajwillia.ms
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com

Jean-Philippe André

2017-07-10 05:42:18 UTC

Permalink

Post by Andrew Williams
I'm curious as to why we've gone from named types back to primitive - is
this just for C bindings?

I was in fact curious as to why we have typedefs for int. IMHO it in fact
harmed readability as you wouldn't know if the type was an integral,
floating point or even a vector (coord could very well have been the 2D x,y
position).
Also there is no way we ever change Evas_Coord to anything else than int
since so much of the internal code assumes 32 bit signed integers.

So I made this call and decided to move to primitive types for our EO API,
where applicable (I also asked around and there was no strong opinion
against).

This was part of a series of patches trying to remove "unnecessary" types
from EO.

Best regards,

Post by Andrew Williams
Andy

Post by Andrew Williams
Hi,

Post by Andrew Williams
It looks like some eo change moved many Evas_Coord to int - is that

correct

Post by Andrew Williams
or did we miss something?

I changed that in commit af3cb1018584e3c403024b.
ABI wise this doesn't change anything at all.
Since the legacy APIs are automatically generated they also use int

instead

Post by Andrew Williams
of Evas_Coord now.
Hope that's not a problem?

Post by Andrew Williams
Andy

19.1/1.20.0-beta1/report.html

Post by Stefan Schmidt
Please have a look at your respective areas and things you changed on
this cycle.
I will also look through it next week and run our own checker as it

had

Post by Andrew Williams

Post by Stefan Schmidt
slightly different results in the past and I want to be sure be cover

both.

Post by Stefan Schmidt
regards
Stefan Schmidt
------------------------------------------------------------

------------------

--
Jean-Philippe André
------------------------------------------------------------

------------------

Post by Andrew Williams
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Jean-Philippe André

Stefan Schmidt

2017-07-13 10:13:13 UTC

Permalink

Hello.

I now had a look at the changes between 1.19.1 and beta2. Going through
them lib by lib as abi-laboratory offers them.

TL;DR
o Is elm_photocam_image_region_set supposed to be a legacy API as well?
o evas_textblock_cursor_equal was removed but seems to be part of our
legacy API.
o Are all of these evas_object_* APIs supposed to be available in legacy
as well?

And here for the more detailed version:

https://abi-laboratory.pro/tracker/objects_report/efl/1.19.1/1.20.0-beta2/report.html

Ecore: 3 new and 4 removed API.
Added and removed symbols are all in ecore_poller as an EO API. No problem.

Ecore_Evas: 1 new and 1 removed API.
New: ecore_evas_cursor_device_unset -> looks fine to me
Removed: ecore_evas_vnc_stop -> no problem as this is a beta API

Ecore_Imf: 3 new APIs:
ecore_imf_context_keyboard_mode_get ( Ecore_IMF_Context* ctx )
ecore_imf_context_mime_type_accept_set ( Ecore_IMF_Context* ctx, char
const* mime_type )
ecore_imf_context_prediction_hint_set ( Ecore_IMF_Context* ctx, char
const* prediction_hint )

Are we happy with the naming and are they useful?

Ecore_Input: 1 new API
ecore_input_joystick_name_get ( int index )
Looks fine to me. Any other opinions?

Ecore_X: 3 new APIs
ecore_x_cursor_hide ( )
ecore_x_cursor_show ( )
ecore_x_dpms_force ( Eina_Bool on )

Everybody happy with them?

Edje: 17 new and 72 removed APIs.
All removed ones EO APIs so not a problem.
For the new ones we have 2 being added to legacy as well.

edje_object_message_signal_recursive_process ( Edje_Object* obj )
edje_object_part_text_prediction_hint_set ( Edje_Object* obj, char
const* part, char const* prediction_hint )

Do we want both of them in legacy? Are we happy with the naming?

EFL: 167 new and 23 removed APIs
Quite some big changes but almost all in EO based APIs. No problem with
them.
I see two symbol changes in our normal Efl.h which _could_ be problematic:
Efl.h, libefl.so.1.19.1
_EFL_GFX_CHANGED [data]
_EFL_GFX_PATH_CHANGED [data]

Looking at commit e79f27ae0cd9800f6e97d28a9b6d9f08a34b19ad which removed
it makes it clear it was behind a EFL_BETA_API_SUPPORT ifdef. No problem.

Eina: 14 new APIs
eina_debug_disable ( )
eina_debug_dispatch ( struct _Eina_Debug_Session* session, void* buffer )
eina_debug_local_connect ( Eina_Bool is_master )
eina_debug_opcodes_register ( struct _Eina_Debug_Session* session,
Eina_Debug_Opcode const* ops, Eina_Debug_Opcode_Status_Cb status_cb,
void* data )
eina_debug_remote_connect ( int port )
eina_debug_session_data_get ( struct _Eina_Debug_Session* session )
eina_debug_session_data_set ( struct _Eina_Debug_Session* session, void*
data )
eina_debug_session_dispatch_get ( struct _Eina_Debug_Session* session )
eina_debug_session_dispatch_override ( struct _Eina_Debug_Session*
session, Eina_Debug_Dispatch_Cb disp_cb )
eina_debug_session_send ( struct _Eina_Debug_Session* session, int dest,
int op, void* data, int size )
eina_debug_session_terminate ( struct _Eina_Debug_Session* session )
eina_debug_timer_add ( unsigned int timeout_ms, Eina_Debug_Timer_Cb cb,
void* data )
eina_debug_timer_del ( Eina_Debug_Timer* t )
eina_file_close_on_exec ( int fd, Eina_Bool on )

Are we happy with them?

Elementary: 115 new and 108 removed APIs
All removed symbols are either in eo.h files or in elm_widget.h which is
not stable. No problem.
Ignoring all the new EO based APIs the new ones for Elm boil down to:
elm_photocam_image_region_set ( Efl_Ui_Image_Zoomable* obj, int x, int
y, int w, int h )
elm_cnp_clipboard_selection_has_owner ( Evas_Object* win )
ELM_CNP_EVENT_SELECTION_CHANGED [data]
elm_code_widget_selection_select_all ( Evas_Object* widget )
elm_entry_prediction_hint_set ( Elm_Entry* obj, char const*
prediction_hint )
elm_menu_open ( Elm_Menu* obj )
elm_win_get ( Evas_Object* obj )

Are we happy with them? Is the photocam region set supposed to be legacy
as well?

EO / EO_dbg: 4 new APIs
efl_cast ( Eo const* eo_id, Efl_Class const* cur_klass )
efl_data_scope_safe_get ( Eo const* obj_id, Efl_Class const* klass_id )
eo_classes_iterator_new ( )
eo_objects_iterator_new ( )

Eolian: 1 new API
eolian_typedecl_function_pointer_get ( Eolian_Typedecl const* tp )
Looks sane to me.

Evas: 70 new and 65 removed APIs
We have one API removed here form a legacy header file:
evas_textblock_cursor_equal ( struct _Eo_Opaque const* obj, struct
_Eo_Opaque const* cur )
I guess we will need to bring this back?
The rest of the removed ones are EO based. No problem.
For the newly added one, ignoring EO based ones, we have:
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 )
evas_object_event_grabber_freeze_when_visible_get (
Efl_Canvas_Object_Event_Grabber const* obj )
evas_object_event_grabber_freeze_when_visible_set (
Efl_Canvas_Object_Event_Grabber* obj, Eina_Bool set )
evas_device_get_by_seat_id ( Evas* eo_e, unsigned int id )
evas_device_seat_id_get ( Evas_Device const* dev )
evas_device_seat_id_set ( Evas_Device* dev, unsigned int id )
evas_language_direction_get ( )
evas_map_coords_get ( Evas_Map const* m, double x, double y, double* mx,
double* my, int grab )
evas_object_event_grabber_add ( Evas* eo_e )
evas_object_intercept_device_focus_set_callback_add ( Evas_Object*
eo_obj, Evas_Object_Intercept_Device_Focus_Set_Cb func, void const* data )
evas_object_intercept_device_focus_set_callback_del ( Evas_Object*
eo_obj, Evas_Object_Intercept_Device_Focus_Set_Cb func )

Are all of these evas_object APIs supposed to be available in legacy as
well?

regards
Stefan Schmidt

Stefan Schmidt

2017-07-13 12:41:41 UTC

Permalink

Hello.

Post by Stefan Schmidt
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover both.

And here is the version from our own checker scripts:
https://devs.enlightenment.org/~stefan/compat_reports/efl/1.19.0_to_1.20.0/compat_report.html

Like last time I found some things reported here but not in the one from
ABI Laboratory. I guess I need to bring this up with Andrey.

Below are just the new or removed symbols as a diff to what I wlaready
review in the other thread.

New:
Ecore_Common.h, libecore.so.1.20.0
ecore_event_type_flush_internal ( int type, ... )

Hmm we have a define here for ecore_event_type_flush but still expose
ecore_event_type_flush_internal() as EAPI. Is that on purpose?

Ecore_Input.h, libecore_input.so.1.20.0
ecore_input_joystick_event_axis_deadzone_get ( )
ecore_input_joystick_event_axis_deadzone_set ( int event_axis_deadzone )

Looks ok to me.

elm_code_widget.eo.legacy.h, libelementary.so.1.20.0
elm_code_widget_can_redo_get ( Elm_Code_Widget* obj )
elm_code_widget_can_undo_get ( Elm_Code_Widget* obj )
elm_code_widget_line_status_toggle ( Elm_Code_Widget* obj,
Elm_Code_Line* line )
elm_code_widget_text_at_cursor_insert ( Elm_Code_Widget* obj, char
const* text )

All of elm_code is still in beta, right?

elm_widget.eo.legacy.h, libelementary.so.1.20.0
elm_widget_focus_manager_factory ( Elm_Widget* obj, Efl_Ui_Focus_Object*
root )
elm_widget_focus_register ( Elm_Widget* obj, Efl_Ui_Focus_Manager*
manager, Efl_Ui_Focus_Object* logical, Eina_Bool full )

Marcel, I guess these are exposed behind a beta api flag?

emile_image.h, libemile.so.1.20.0
emile_image_callback_set ( Emile_Image* image, Emile_Action_Cb callback,
Emile_Action action, void const* data )

Seems to be the rename from the removal below.

Removed:

efl_canvas_object.eo.legacy.h, libevas.so.1.19.0
evas_object_pointer_device_in_get ( Efl_Canvas_Object const* obj,
Efl_Input_Device* pointer )
evas_object_pointer_in_get ( Efl_Canvas_Object const* obj )
evas_object_pointer_mode_by_device_get ( Efl_Canvas_Object const* obj,
Efl_Input_Device* dev )
evas_object_pointer_mode_by_device_set ( Efl_Canvas_Object* obj,
Efl_Input_Device* dev, enum Efl_Input_Object_Pointer_Mode pointer_mode )
evas_object_seat_focus_add ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_check ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_del ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_get ( Efl_Canvas_Object const* obj )

They have been exposed as legacy before. If they have not been behind a
beta api flag we need to restore them

elm_code_widget.eo.legacy.h, libelementary.so.1.19.0
elm_code_widget_text_line_number_width_get ( Elm_Code_Widget* obj )

Beta I guess.

emile_image.h, libemile.so.1.19.0
emile_image_register ( Emile_Image* image, Emile_Action_Cb callback,
Emile_Action action, void const* data )

This somehow rings a bell. Did we discuss this before? Cedric?

regards
Stefan Schmidt

Andrew Williams

2017-07-13 16:51:45 UTC

Permalink

Yup, elm_code stuff is still beta.

Andy

Post by Stefan Schmidt
Hello.

Post by Stefan Schmidt
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover

both.
https://devs.enlightenment.org/~stefan/compat_reports/efl/1.19.0_to_1.20.0/compat_report.html
Like last time I found some things reported here but not in the one from
ABI Laboratory. I guess I need to bring this up with Andrey.
Below are just the new or removed symbols as a diff to what I wlaready
review in the other thread.
Ecore_Common.h, libecore.so.1.20.0
ecore_event_type_flush_internal ( int type, ... )
Hmm we have a define here for ecore_event_type_flush but still expose
ecore_event_type_flush_internal() as EAPI. Is that on purpose?
Ecore_Input.h, libecore_input.so.1.20.0
ecore_input_joystick_event_axis_deadzone_get ( )
ecore_input_joystick_event_axis_deadzone_set ( int event_axis_deadzone )
Looks ok to me.
elm_code_widget.eo.legacy.h, libelementary.so.1.20.0
elm_code_widget_can_redo_get ( Elm_Code_Widget* obj )
elm_code_widget_can_undo_get ( Elm_Code_Widget* obj )
elm_code_widget_line_status_toggle ( Elm_Code_Widget* obj,
Elm_Code_Line* line )
elm_code_widget_text_at_cursor_insert ( Elm_Code_Widget* obj, char
const* text )
All of elm_code is still in beta, right?
elm_widget.eo.legacy.h, libelementary.so.1.20.0
elm_widget_focus_manager_factory ( Elm_Widget* obj, Efl_Ui_Focus_Object*
root )
elm_widget_focus_register ( Elm_Widget* obj, Efl_Ui_Focus_Manager*
manager, Efl_Ui_Focus_Object* logical, Eina_Bool full )
Marcel, I guess these are exposed behind a beta api flag?
emile_image.h, libemile.so.1.20.0
emile_image_callback_set ( Emile_Image* image, Emile_Action_Cb callback,
Emile_Action action, void const* data )
Seems to be the rename from the removal below.
efl_canvas_object.eo.legacy.h, libevas.so.1.19.0
evas_object_pointer_device_in_get ( Efl_Canvas_Object const* obj,
Efl_Input_Device* pointer )
evas_object_pointer_in_get ( Efl_Canvas_Object const* obj )
evas_object_pointer_mode_by_device_get ( Efl_Canvas_Object const* obj,
Efl_Input_Device* dev )
evas_object_pointer_mode_by_device_set ( Efl_Canvas_Object* obj,
Efl_Input_Device* dev, enum Efl_Input_Object_Pointer_Mode pointer_mode )
evas_object_seat_focus_add ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_check ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_del ( Efl_Canvas_Object* obj, Efl_Input_Device*
seat )
evas_object_seat_focus_get ( Efl_Canvas_Object const* obj )
They have been exposed as legacy before. If they have not been behind a
beta api flag we need to restore them
elm_code_widget.eo.legacy.h, libelementary.so.1.19.0
elm_code_widget_text_line_number_width_get ( Elm_Code_Widget* obj )
Beta I guess.
emile_image.h, libemile.so.1.19.0
emile_image_register ( Emile_Image* image, Emile_Action_Cb callback,
Emile_Action action, void const* data )
This somehow rings a bell. Did we discuss this before? Cedric?
regards
Stefan Schmidt
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
http://andywilliams.me
http://ajwillia.ms

Stefan Schmidt

2017-07-14 08:19:11 UTC

Permalink

Hello.

Post by Stefan Schmidt
Hello.

Post by Stefan Schmidt
I will also look through it next week and run our own checker as it
had slightly different results in the past and I want to be sure be
cover both.

https://devs.enlightenment.org/~stefan/compat_reports/efl/1.19.0_to_1.20.0/compat_report.html

Jean-Philippe André

2017-07-17 02:19:20 UTC

Permalink

Hi,

Cedric, Mike,

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.

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'll have a closer look at the rest of the APIs soon.

Post by Stefan Schmidt
Hello.

Post by Stefan Schmidt
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover both.

https://devs.enlightenment.org/~stefan/compat_reports/efl/1.
19.0_to_1.20.0/compat_report.html

On the same URL you will now find an updated report. Seems I had a 1.19
dump around which was not from the final release but a few days before. The
emile API change was never in the final 1.19 release as Cedric pointed out
to me.
The good thing is that I can see no difference between our report and the
one from ABI labs anymore now. :) Sorry for the hassle.
regards
Stefan Schmidt
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Jean-Philippe André

Stefan Schmidt

2017-07-20 15:11:45 UTC

Permalink

Cedric, Mike,

Could you please comment on JP's review.
We are in beta3 now and if we need to fix some new API it is now.

Post by Jean-Philippe AndrÃ©
Hi,
Cedric, Mike,
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.
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'll have a closer look at the rest of the APIs soon.

Post by Stefan Schmidt
Hello.

Post by Stefan Schmidt
I will also look through it next week and run our own checker as it had
slightly different results in the past and I want to be sure be cover both.

https://devs.enlightenment.org/~stefan/compat_reports/efl/1.
19.0_to_1.20.0/compat_report.html

Cedric BAIL

2017-07-20 20:38:05 UTC

Permalink

Hi,

Post by Jean-Philippe AndrÃ©
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.

Post by Jean-Philippe AndrÃ©
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

Jean-Philippe André

2017-07-21 01:48:39 UTC

Permalink

Post by Cedric BAIL
Hi,

Post by Jean-Philippe AndrÃ©
efl_canvas_object.eo.legacy.h, libevas.so.1.20.0
evas_object_pointer_coords_inside_get ( Efl_Canvas_Object* obj, int x,

int

Post by Jean-Philippe AndrÃ©
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.

Post by Cedric BAIL

the

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é