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
