s/teori/theory/ On Mon, Sep 19, 2016 at 6:27 PM, Guilherme Íscaro <isc...@profusion.mobi> wrote:
> > > On Fri, Sep 16, 2016 at 6:17 PM, Christopher Michael < > cp.mich...@samsung.com> wrote: > >> On 09/16/2016 05:11 PM, Guilherme Íscaro 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. >> > - >> > >> >> I still maintain that any functions dealing with a single specific seat >> are going to come back and bite you when true multi-seat is >> implemented... perhaps (for those type of functions) they should have a >> parameter "seat" or something ??? If no seat is passed in, then assume >> "default" seat... >> >> dh >> > > Hey Christopher, > > In teori we plan to refactor evas_canvas_pointer_canvas_xy_get() and make > it use evas_canvas_seat_pointer_canvas_xy_get() internally. Do you > think this might be a problem as well ? > > >> > 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 >> > - >> > >> > 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). >> > - >> > >> > 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….); >> > - >> > >> > 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 >> > screen. >> > >> > >> > >> > = 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 >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> >> >> ------------------------------------------------------------ >> ------------------ >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
