Hello. On 13/08/16 05:16, Carsten Haitzler (The Rasterman) wrote: > On Fri, 12 Aug 2016 18:31:34 +0200 Stefan Schmidt <ste...@osg.samsung.com> > said: > >> Hello. >> >> On 12/08/16 11:37, Tom Hacohen wrote: >>> On 07/06/16 13:36, Tom Hacohen wrote: >>>> Hey, >>>> >>>> This is the first ABI report since the merge of Elm. It should correctly >>>> compare. I compared against 1.17 as if elementary was already merged in. >>>> >>>> With that being said, this one is obviously a giant mess. The signatures >>>> changed for *all* of the Eo functions because of Eo4 and the interfaces >>>> work. >>>> >>>> Please take a look if you like the new functions added, and ignore the >>>> Eo ones that got removed. >>>> >>>> We also need to make sure we don't keep around in ugly APIs that were >>>> created in older Eo incarnations and should have been migrated to the >>>> Efl namespace but haven't. >>>> >>>> As usual: >>>> https://devs.enlightenment.org/~tasn/abi/ >>> >>> >>> Updated according to the current state. >> >> >> Raster, I looked through the whole report now and fixed some more >> missing since tags. The items below I'm unsure about so I wanted to get >> another opinion before changing things. I also cherry-picked all of your >> commits plus mine up to now from 1.18 to master. >> >> Things that look suspicious to me: >> >> Edje_Common.h, libedje.so.1.18.0 >> edje_mmap_3d_has ( Eina_File* f, char const* group ) >> >> From commit 52df6171e9287dd588968ed968fee7e72cfaf080. Is this something >> we should have public? The rest of our 3d work is still marked as BETA. >> This one not. > > this just lets you know if it does have 3d. tbh i dislike this because... why > does it matter? you shouldn't need to know or care. we can do 3d in software. > we use osmesa for this. yes it's sluggish, but it works. it's portable. this > stuff should work and be portable regardless of engine - all we are arguing is > speed. it's used in edje_player so it has to be exposed, but in general i find > the logic behind this api "dubious". but at this point we may as well keep it. > >> --- >> >> efl_canvas_object.eo.legacy.h, libevas.so.1.18.0 >> evas_object_legacy_ctor ( Efl_Canvas_Object* obj ) >> >> The doc says internal function do not use. It seems not to be used in >> legacy anyway. Is it really needed to make this EAPI? > > fixed. eolian_gen issue. q66 did ti. i cherry-picked the commit. > >> --- >> >> efl_canvas_text.eo.legacy.h, libevas.so.1.18.0 >> evas_object_textblock_visible_range_get ( Efl_Canvas_Text* obj, >> Efl_Canvas_Text_Cursor* start, Efl_Canvas_Text_Cursor* end ) >> >> Introduced in commit c297ff4115ba99f212c59dc8ed2430bcd7c8ad6b. The doc >> mark it actually with a since 1.1 but I have no place where this is >> being used in legacy. Is legacy really needed here? > > that smells like a typo for version. 1.18 :) i think this ios validly added to > legacy api's to extend functionality... so just fixing typo is enough. > >> --- >> >> efl_canvas_text_cursor.eo.legacy.h, libevas.so.1.18.0 >> evas_textblock_cursor_equal ( Efl_Canvas_Text_Cursor const* obj, >> Efl_Canvas_Text_Cursor const* cur ) >> >> Same as the above. I can't find legacy users. Introduced in commit >> c297ff4115ba99f212c59dc8ed2430bcd7c8ad6b > > same - missing a @since 1.18 > >> --- >> >> efl_loop_timer.eo.legacy.h, libecore.so.1.18.0 >> ecore_timer_loop_reset ( Efl_Loop_Timer* obj ) >> >> >> I see no user in legacy for this one. Maybe mark as legacy: null? > > i see the point of this though and it has an @since. so this is ok. reset uses > "now" as the new start time, loop_reset uses the loop wakeup time as the new > start time. > >> --- >> >> efl_ui_win.eo.legacy.h, libelementary.so.1.18.0 >> elm_win_name_get ( Efl_Ui_Win const* obj ) >> >> The set function is marked with legacy: null. Is get supposed to be >> available for legacy, if yes, we need to add a since tag. > > i see no reason not to have a get... just need an @since :) > >> --- >> >> Evas_Legacy.h, libevas.so.1.18.0 >> evas_object_text_filter_program_set ( Evas_Object* obj, char const* code ) >> evas_object_text_filter_source_set ( Evas_Object* obj, char const* name, >> Evas_Object* source ) >> >> Are text filters supposed to be available in legacy? > > check the commit. they are. the are missing @since. :) fixed. > >> --- >> >> Removed symbols: Ecore_Wayland.h header file seems not be used in this run. > > it just wasnt built. we've moved on to ecore-wl2 anyway ... :) > >> --- >> >> elm_photo.eo.legacy.h, libelementary.so.1.17.0 >> [−] elm_photo_thumb_set ( Elm_Photo const* obj, char const* file, char >> const* group ) (1) >> changed to: >> elm_photo_thumb_set ( Evas_Object* obj, char const* file, char const* >> group ) >> >> We should probably make sure that the obj stays const here? > > technically this sounds like a fix. the object is modified. the object > properties are changed... this smells right and like a fix. it doesn't break > api/abi. > >> --- >> >> elm_win.eo.legacy.h, libelementary.so.1.17.0 >> [−] elm_win_main_menu_get ( Elm_Win const* obj ) (1) >> changed to: >> elm_win_main_menu_get ( Evas_Object* obj ) >> >> Same as the last one. > > actually this api happens to modify internal window state - creates a menu > etc. so this is right. > >> --- >> >> elm_win_legacy.h, libelementary.so.1.17.0 >> [−] elm_win_wm_rotation_preferred_rotation_set ( Evas_Object const* obj, >> int rotation ) (1) >> changed to: >> elm_win_wm_rotation_preferred_rotation_set ( Evas_Object* obj, int >> rotation ) >> >> Again, same as before. > > well this is like the first. it should NOT be const. the object is modified. > it's a set. :) so this is fixed. > >> --- >> >> evas_textblock.eo.legacy.h, libevas.so.1.17.0 >> [−] evas_object_textblock_text_markup_get ( Evas_Textblock const* obj ) (1) >> changed to: >> evas_object_textblock_text_markup_get ( Evas_Object* obj ) >> [−] evas_textblock_node_format_first_get ( Evas_Textblock const* obj ) (1) >> changed to: >> evas_textblock_node_format_first_get ( Evas_Object* obj ) >> [−] evas_textblock_node_format_last_get ( Evas_Textblock const* obj ) (1) >> changed to: >> evas_textblock_node_format_last_get ( Evas_Object* obj ) > > hmm. ok these are from auto generated legacy code. thus its hard to force the > const to be there. it doesn't know if the get happens to modify the obj. this > doesnt really break api or abi so i think we're ok here. > >> And one last time. >> >> --- >> >> elm_image_common.h >> [+] ELM_IMAGE_FLIP_HORIZONTAL >> [+] ELM_IMAGE_FLIP_TRANSPOSE >> [+] ELM_IMAGE_FLIP_TRANSVERSE >> [+] ELM_IMAGE_FLIP_VERTICAL >> [+] ELM_IMAGE_ORIENT_0 >> [+] ELM_IMAGE_ORIENT_180 >> [+] ELM_IMAGE_ORIENT_270 >> [+] ELM_IMAGE_ORIENT_90 >> [+] ELM_IMAGE_ORIENT_NONE >> [+] ELM_IMAGE_ROTATE_180 >> [+] ELM_IMAGE_ROTATE_270 >> [+] ELM_IMAGE_ROTATE_90 >> >> These constants seems to have moved to elm_image_legacy.h and the abi >> checker just got confused. Better someone to double check me here. > > i double checked. they all match the same abi values here. so we're ok. > > i'm done with going over yours above. i cherry-picked my branch fixes back to > master too. > > so if these above are done... do you think we're good? everyone else?
With all of the above either fixed or clarified I'm good. Is anybody else reviewing these right now wants us to wait before we hopefully to the final 1.18? regards Stefan Schmidt ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
