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. > 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. :) > ------------------------------------------------------------------------------ > _______________________________________________ > 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
