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

Reply via email to