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