On 16 August 2016 at 11:38, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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. > <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > Well... I fixed a few more things I could spot. I believe we're good now. -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
