Hello, I found something else:
- evas_out_add - evas_output_del - evas_output_engine_info_get - evas_output_engine_info_set - evas_output_view_get - evas_output_view_set where removed, but they have been part of the stable api ... they are even flagged with @since 1.8, i think they should come back Also, struct _Elm_Widget_Item_Data has been changed, should we bump the internal elementary api version? Greetings Marcel Hollerbach On Tue, Feb 28, 2017 at 09:23:31AM +0100, Stefan Schmidt wrote: > Hello. > > On 02/28/2017 02:04 AM, Jean-Philippe André wrote: > > Hi, > > > > On 28 February 2017 at 07:04, Stefan Schmidt <ste...@osg.samsung.com> wrote: > > > >> Hello. > >> > >> Most of these are sorted but I still want some feedback/comments on the > >> remaining two items: > >> > >> On 02/15/2017 12:04 PM, Stefan Schmidt wrote: > >>> > >>> Ecore_Evas.h, libecore_evas.so.1.19.0 > >>> ecore_evas_cursor_device_get ( Ecore_Evas const* ee, Efl_Input_Device* > >>> pointer, Evas_Object** obj, int* layer, int* hot_x, int* hot_y ) > >>> ecore_evas_object_cursor_device_set ( Ecore_Evas* ee, Efl_Input_Device* > >>> pointer, Evas_Object* obj, int layer, int hot_x, int hot_y ) > >>> > >>> Why has the set a _object_ in the function name and the get not? > >> > >> Guilherme, you added these two. Can you explain the naming difference to > >> me? > >> > >>> edje_object.eo.legacy.h, libedje.so.1.19.0 > >>> edje_object_seat_get ( Edje_Object const* obj, Eina_Stringshare* name ) > >>> edje_object_seat_name_get ( Edje_Object const* obj, Efl_Input_Device* > >>> device ) > >>> > >>> 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 ) > >>> > >>> Is the seat stuff supposed to be exposed to legacy? I can see them used > >>> in src/lib/edje/edje_program.c, but I wonder if they should wait for > >>> interfaces or should be exposed now. > >> > >> Guilherme, Bruno, Gustavo, was the legacy exposal of these APIs on > >> purpose? We would have to maintain them in the future so I would like to > >> be sure that there is a good reason to expose them at this point. > >> > > > > Note that we can also just mark them as beta for now, if that helps. > > Until multi-seat is mostly figured out and implemented, it may help to mark > > all related features as beta. What do you think? > > I would be ok with that. In case they are actually needed in legacy and > not only exposed by accident. > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
