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

Reply via email to