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

   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

   evas_object_focus_set() - his function will be refactored to use

   evas_canvas_object_focus_by_seat_set() should be added

   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

   When a device is removed another event will be generated

   Every time an object/canvas receives focus a new event will be
   generated. The event
   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….);

      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.

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

= 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

= 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.

= Ecore =


   Ecore_Events structs should contain the Efl_Input_Device that originated
   the event.


   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 ;-)
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
enlightenment-devel mailing list

Reply via email to