Hi,

On 17 September 2016 at 06:11, Guilherme Íscaro <isc...@profusion.mobi>
wrote:

> Hey guys, Here's a version 2.
>
> = Changes on Evas =
>
>    -
>
>    _Evas_Public_Data should contain a hash indexed by seat of focused
>    Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>    -
>
>    evas_canvas_focus_get() should return the object focused by the default
>    seat.
>    -
>
>    evas_canvas_pointer_canvas_xy_get() Should return the XY from the
>    default seat.
>    -
>
>    evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
>    evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
> on the
>    seat.
>    -
>
>    evas_object_focus_set() - his function will be refactored to use
>    evas_canvas_object_focus_by_seat_set().
>    -
>
>    evas_canvas_object_focus_by_seat_set() should be added
>    -
>

I would rather not have any new legacy function. All new or existing EO
functions should have an @optional seat object (where relevant).
At the moment it seems Efl.Input.Device can represent a seat, and an input
device should have a seat as a parent. If this design is OK, then let's
keep it that way.

Note that all I did when "creating" Efl.Input.Device was convert
Evas_Device to EO and avoid merging a patch where we introduce a different
struct for Ecore_Device.
Now, if we have device info at ecore level, it will be forwarded to evas
automatically. In theory. Nothing in upstream code actually does this yet :(


>    Evas will automatically create Evas_Devices
>    -
>
>    All functions that handle multi-seat should be implement as non-legacy,
>    this is using EO.
>    -
>
>    For every new Evas_Device creation an event
>    (EFL_CANVAS_EVENT_DEVICE_ADD) should be generated containing the new
>    Evas_Device.
>    -
>
>    When a device is removed another event will be generated
>    (EFL_CANVAS_EVENT_DEVICE_DEL).
>

I agree that those 2 extra events make sense. Currently CHANGED is
triggered for ADD. A legacy wrapper needs to forward a change on both add
and change.



>    -
>
>    Every time an object/canvas receives focus a new event will be
>    generated. The event
>    (EFL_CANVAS_EVENT_DEVICE_FOCUS_IN/OUT)/(EFL_CANVAS_
> EVENT_OBJECT_DEVICE_FOCUS_IN/OUT)
>    will contain the device itself that generated the focus event and the
>    focused object/canvas.
>    -
>
>    Add new EO event functions: evas_canvas_event_*(EO *evas, Evas_Device
>    *device_that_originated_the_event, ...Event Args….);
>

There shouldn't be any new (legacy or eo) function for that.
Events are not "fed" anymore but simply forged and sent with
efl_event_callback_call. ecore_evas or evas do that.

Legacy C API will simply not support multi-seat (only default seat / NULL).


>    -
>
>       All the existing evas_events_*() functions will be refactored to use
>       the new event functions passing NULL as device, this will flag
> that device
>       belongs to the default seat.
>

Yes.


>       -
>
>       Internally EFL will be refactored to replace the old evas_event_*
>       functions and use the new ones.
>

No. As above, we don't call a feed function to feed events to evas.
Instead, we send an event to evas (yes, the Evas * eo object).



> = Changes on Ecore_Evas =
>
>    -
>
>    Eina_Bool ecore_evas_x11_vnc_server_start(Ecore_Evas *ee, const char
>    *addr, int port, Accept_Client_Cb cb, void *cb_data); -> This will
> enable
>    vnc server for the ecore_evas x11 module.
>    -
>
>    The Accept_Client_Cb will have the following signature: typedef
>    Eina_Bool (Accept_Client_Cb)(void *data, Ecore_Evas *ee, const char
>    *client_addr). This callback should return EINA_TRUE to accept the VNC
>    client or EINA_FALSE otherwise.
>    -
>
>    The struct _Ecore_Evas_Interface_X11 should contain a new function with
>    the following signature Eina_Bool _setup_vnc_server() that will create
> the
>    vnc server and start listening for clients.
>    -
>
>    ecore_evas_x11_vnc_server_stop(Ecore_Evas *ee);
>    -
>
>    Ecore_Evas_x11 will create Efl_Input_Devices for every new user and set
>    the emulated seat.
>    -
>
>    In case of x11 - For every new vnc client an Efl_Input_Device will be
>    created and added to the Evas canvas.


>
>
> = Changes on Evas x11 engine =
>
>    -
>
>    A callback will be created in order to notify the ecore_evas_x11 backend
>    with the modified pixels. This will be used to properly draw the VNC
> remote
>    screen.
>

So VNC would be used to allow a second client to remotely connect to a
running app on X? Interesting...
Though I believe proper Wayland support for multi-seat is more important
right now :)



>
>
>
> = Changes on Ecore_Wl2 =
>
>    -
>
>    Implement the _seat_cb_name() function in order to collect the seat
> name.
>    -
>
>    For every wl_pointer/wl_keyboard/wl_seat it will be create an
>    Efl_Input_Device. The wl_pointer and wl_keyboard will have the wl_seat
> as
>    parent. After creation of these Efl_Input_Devices an ecore_event will be
>    generated, so ecore_evas_input can grab it and properly add the devices
>    into the canvas.
>
>
yes


>
>
> = Ecore =
>
>    -
>
>    Ecore_Events structs should contain the Efl_Input_Device that originated
>    the event.
>

yes


>
>
>    -
>
>    These functions may be useful:
>    -
>
>       Eina_List *ecore_input_seats_get() - Return all the available seats
>       - Ecore_Seat * ecore_input_seat_find(const char *name)
>
>
> On Fri, Sep 16, 2016 at 12:51 PM, Gustavo Sverzut Barbieri <
> barbi...@gmail.com> wrote:
>
> > On Thu, Sep 15, 2016 at 10:47 PM, Derek Foreman <der...@osg.samsung.com>
> > wrote:
> > > On 15/09/16 10:51 AM, Gustavo Sverzut Barbieri wrote:
> > >> On Wed, Sep 14, 2016 at 3:42 PM, Derek Foreman <
> der...@osg.samsung.com>
> > wrote:
> > >>> Wayland does have separate focus for pointer, keyboard, and touch
> > within
> > >>> a seat - and there's no "seat focus" at all.
> > >>
> > >> Ok, that helps so we'll basically add focus per device, since your
> > >> previous explanation that there is a single pointer/keyboard/touch per
> > >> seat, it should work nice. For us it avoids one "parent lookup" to
> > >> figure out the seat of a given device :-)
> > >>
> > >> BUT one thing that we need to understand is the relation between
> > >> pointer/touch and keyboard focus, this is particularly important so we
> > >> plan a solution that works for legacy EFL (or any toolkit that has a
> > >> single focused object).
> > >>
> > >> Usually we have one focused object (ie:  text entry). Clicking or
> > >> taping (touch) it, will focus. Then typing at the keyboard will send
> > >> keys there. If you use the keyboard to cycle focus (ie: Tab), then
> > >> that object previously focused by pointer/touch is unfocused and a new
> > >> one is focused.
> > >>
> > >> If pointer and touch are not changing that focus where keyboard send
> > >> key presses... what are they use? This is why we're planning per-seat
> > >> focus: be click, tap or "Tab", change the focused object where the
> > >> next key press will be delivered.
> > >
> > > Well, in wayland "activation" (window is "focused" and decorates itself
> > > as such) is sent separately from input events.  Pointer focus generally
> > > means the pointer is inside a window - whether that activates the
> window
> > > or not is up to the compositor (focus follows mouse vs click to focus,
> > etc)
> > >
> > > On weston, when you mouse into a window it will receive a pointer enter
> > > event (and have pointer focus) before it receives any pointer motion
> > > events - but it won't be activated unless you click.  Weston also sets
> > > the keyboard focus when you click.
> > >
> > > But I'm talking about how the compositor delivers events, not how
> > > applications use them (pointer, touch, keyboard may focus on difference
> > > surfaces in wayland... but how an application focuses widgets on its
> > > canvas is entirely up to the application?)
> > >
> > > Wayland doesn't know anything about "widget focus".  That's up to the
> > > application to define.
> > >
> > >> The idea of multi-seat here is to allow 2 users to simultaneously use
> > >> the same application window, like 2 text entries, each user would be
> > >> sending text to his own entry (we're not attempting to do multi-user
> > >> edit of the same text-entry, as that will be much more complex given
> > >> Evas textblock).
> > >
> > > I think it's probably completely reasonable to think of a seat as
> having
> > > a focus at this level.
> >
> > nice, it was more like a terminology and scope thing then :-)
> >
> >
> >
> > >> Another use is to allow 2 users to interact with different edje drag
> > >> parts, or in a game you can control 2 players at once.
> > >
> > > A shame libinput doesn't do anything for gamepads.  I'll assume that's
> > > outside of the scope of this work. :)
> >
> > maybe another day ;-)
> >
>
> Best regards,

-- 
Jean-Philippe André
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to