Hello. On Wed, 2014-05-07 at 01:15, Daniel Juyung Seo wrote: > > On Tue, May 6, 2014 at 8:51 PM, Stefan Schmidt > <[email protected]>wrote: > > > Hello. > > > > On Wed, 2014-04-30 at 16:11, Tom Hacohen wrote: > > > Hey, > > > > > > As promised, these are my ABI reports. There's a bit of noise because of > > > the switch to Eo2 and the fact that our object's Eo API is not always > > > ifdefed out in the headers (the Eo api is though, so they can't be used > > > without the define). Also, obviously, the symbols exposed in the binary > > > that can not be turned off. I think though, that it's easy enough to > > > scan through the noise and find the issues. > > > > > > Here's the new index for all the scans: > > > http://enlightenment.org/~tasn/abi/ > > > > > > > > > Please have a look and share if you see anything suspicious. > > > > I like to have some more people looking over this. The list out of my > > head would be raster, cedric and k-s as they have expenrience with > > this but obviously everyone is welcome. > > > > I will go through elm. Elm didn't get enough love from core developers so I > would like to volunteer for it.
Thanks! > > > A good example would be: > > > [+] elm_widget_focus_highlight_geometry_get ( Evas_Object const* obj, > > > Evas_Coord* x, Evas_Coord* y, Evas_Coord* w, Evas_Coord* h ) (1) > > > > > > But I guess that's "fine" because it's internal. > > > > The application linked against the old lib and now switching to the > > new one should still work with this. A problem arises this new > > parameter changes the behaviour if not set. Its available through > > elm_widget.h so its not really internal. > > > > It is officially internal. > Looking at elm_widget.h header, it says: > DO NOT USE THIS HEADER UNLESS YOU ARE PREPARED FOR BREAKING OF YOUR > CODE. THIS IS ELEMENTARY'S INTERNAL WIDGET API (for now) AND IS NOT > FINAL. CALL elm_widget_api_check(ELM_INTERNAL_API_VERSION) TO CHECK > IT AT RUNTIME. > > And the parameter does not affect the behavior at all. I will remove the > parameter. > So the change is acceptable to me. Its internal, fair enough. API can change without a problem as long as we make sure all internal users change as well. No need to change it. > > o There are some other symbols added though which one can easily miss. > > Listing them here and I would like to hear comments if we are fine > > with maintaining these new APIs > > > > Newly added symbols: > > > > elm_config.h, libelementary.so.1.10.0 > > elm_config_accel_preference_get ( ) > > elm_config_accel_preference_set ( char const* pref ) > > elm_config_atspi_mode_get ( ) > > elm_config_atspi_mode_set ( Eina_Bool is_atspi ) > > elm_config_color_classes_list_free ( Eina_List* list ) > > elm_config_color_classes_list_get ( ) > > elm_config_color_overlay_apply ( ) > > elm_config_color_overlay_list_get ( ) > > elm_config_color_overlay_set ( char const* color_class, int r, int g, int > > b, int a, int r2, int g2, int b2, int a2, int r3, int g3, int b3, int a3 ) I have to say that I find an API call with 13 parameters annoyingly to use. :) > > elm_config_color_overlay_unset ( char const* color_class ) > > elm_config_focus_auto_scroll_bring_in_enabled_get ( ) > > elm_config_focus_auto_scroll_bring_in_enabled_set ( Eina_Bool enabled ) > > elm_config_focus_highlight_clip_disabled_get ( ) > > elm_config_focus_highlight_clip_disabled_set ( Eina_Bool disable ) > > elm_config_focus_move_policy_get ( ) > > elm_config_focus_move_policy_set ( enum Elm_Focus_Move_Policy policy ) > > elm_config_item_select_on_focus_disabled_get ( ) > > elm_config_item_select_on_focus_disabled_set ( Eina_Bool enabled ) > > > > elm_focus.h, libelementary.so.1.10.0 > > elm_object_focused_item_get ( Evas_Object const* obj ) > > elm_object_item_focus_get ( Elm_Object_Item const* it ) > > elm_object_item_focus_set ( Elm_Object_Item* it, Eina_Bool focused ) > > > > elm_scroll.h, libelementary.so.1.10.0 > > elm_object_scroll_item_loop_enabled_get ( Evas_Object const* obj ) > > elm_object_scroll_item_loop_enabled_set ( Evas_Object* obj, Eina_Bool > > enable ) > > > > elm_widget.h, libelementary.so.1.10.0 > > _elm_widget_item_focus_get ( Elm_Widget_Item const* item ) > > _elm_widget_item_focus_get_hook_set ( Elm_Widget_Item* item, > > Elm_Widget_Focus_Get_Cb func ) > > _elm_widget_item_focus_set ( Elm_Widget_Item* item, Eina_Bool focused ) > > _elm_widget_item_focus_set_hook_set ( Elm_Widget_Item* item, > > Elm_Widget_Focus_Set_Cb func ) > > elm_widget_focus_highlight_enabled_get ( Evas_Object const* obj ) > > elm_widget_focus_highlight_focus_part_geometry_get ( Evas_Object const* > > obj, Evas_Coord* x, Evas_Coord* y, Evas_Coord* w, Evas_Coord* h ) > > elm_widget_focused_item_get ( Evas_Object const* obj ) > > elm_widget_item_loop_enabled_get ( Evas_Object const* obj ) > > elm_widget_item_loop_enabled_set ( Evas_Object* obj, Eina_Bool enable ) > > elm_gengrid.eo.legacy.h, libelementary.so.1.10.0 > > elm_gengrid_wheel_disabled_get ( Eo const* obj ) > > elm_gengrid_wheel_disabled_set ( Eo* obj, Eina_Bool disabled ) > > > > > > > All look ok to me. Naming seems to be in line with what we use for a public API and nothing stood out for me as well. But for these things the devil often is in the details. More eyes appreciated here. > > I also wonder why we have some newly added symbols in the generated legacy > > headers. Should they not cover what we already had thus legacy? > > > > > As far as I understand, legacy will still be used until 2.0 and new APIs > can be added as a legacy interface. > If someone does not use eo interface but they need a new API, they can add > new API to the legacy API sets. Yeah, I was a bit confused here but I got enlightened on IRC about it. > > elm_gengrid_legacy.h, libelementary.so.1.10.0 > > elm_gengrid_reorder_mode_start ( Evas_Object* obj, Ecore_Pos_Map > > tween_mode ) > > elm_gengrid_reorder_mode_stop ( Evas_Object* obj ) > > > > elm_photo.eo.legacy.h, libelementary.so.1.10.0 > > elm_photo_editable_get ( Eo const* obj ) > > elm_photo_fill_inside_get ( Eo const* obj ) > > elm_photo_size_get ( Eo const* obj ) > > > > elm_route.eo.legacy.h, libelementary.so.1.10.0 > > elm_route_emap_set ( Eo* obj, void* emap ) > > > > > Gengrid APIs are added on purpose. > Other APIs are added indirectly by Eolian adoption. > Still looks ok to me. OK > > o Removed symbols seem only to come from the eo2 change which we have > > declared unstable right now. But please have another look if that is > > correct: > > > > elm_atspi_object_eo.h, libelementary.so.1.9.3 > > elm_atspi_component_interface_get ( ) > > elm_atspi_obj_class_get ( ) > > elm_atspi_widget_obj_class_get ( ) > > elm_atspi_window_interface_get ( ) > > > > elm_interface_fileselector.h, libelementary.so.1.9.3 > > elm_fileselector_interface_get ( ) > > > > elm_interface_scrollable.h, libelementary.so.1.9.3 > > elm_obj_pan_eo_class_get ( ) > > elm_scrollable_interface_get ( ) > > > > > Not sure about the removal of scrollable/fileselector_interface_get() APIs. > They were published in public headers. > Need to listen to others' opinions. Its an API break if it was available through public headers before and we remove it now. Why was it removed? Who did it? These look like problems and we need to find out about them and fix before the release. > > elm_web_legacy.h, libelementary.so.1.9.3 > > elm_web_uri_get ( Evas_Object const* obj ) > > > > ^^^^ This one looks suspicious to me. Can our elm and webkit people please > > comment on this removal? > > > > > It was removed by Daniel Zaoui in his commit > 5c519e5aa410bb5a24e550eb796f911b681d0102. > This looks like a mistake. It should not happen. Indeed. Thanks for finding the right commit. JackDanielz needs to fix this. Pinged him on irc. > > elm_widget.h, libelementary.so.1.9.3 > > elm_widget_class_get ( ) > > > > Acceptable to me because it is an internal API. OK > > elm_map_legacy.h, libelementary.so.1.9.3 > > [−] elm_map_canvas_to_region_convert ( Evas_Object const* obj, Evas_Coord > > const x, Evas_Coord const y, double* lon, double* lat ) (2) > > changed to: > > elm_map_canvas_to_region_convert ( Eo const* obj, Evas_Coord x, Evas_Coord > > y, double* lon, double* lat ) > > > > The removal of the const here can cause us trouble or am I wrong? > > > > Hmm this is weird. The API was wrongly designed at the first time. > In elm-1.9, the header mentioned x and y as "const" but in elm_map.c their > values were changed by pointer dereferencing. > So it was not "const" for real. That sounds really messy. So we had it wrong in the first place and now have to break the API to get it right. Sigh. Is it acceptable to do that? I don't know. Something to think about. Thanks for your input! regards Stefan Schmidt ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
