On Thu, 15 Sep 2016 20:47:34 -0500 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. > > > 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. :) For what it is worth, VRPN does handle gamepads, as well as all sorts of odd input devices like 3D mice, etc. It was highly recommended to me, but I've not tried it yet. https://github.com/vrpn/vrpn/wiki Not so obvious, but it only handles input devices, it just classes the tracking of HMDs as input devices. OSVR does handle the display part, and uses VRPN for the input. I mention this in https://phab.enlightenment.org/w/research_items/hmd_support/ -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
