On Mon, 15 Aug 2016 10:44:00 +0200 Stefan Schmidt <ste...@osg.samsung.com> said:
> 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? release it. looks like no one has any objections anymore. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
