Compositor grabs (was: Re: [PATCH] protocol: Add DnD actions)

[Michal Suchanek]

On 17 April 2015 at 14:16, Carlos Garnacho <carlosg at gnome.org> wrote:
> Hey Jonas,
>
> This is drifting a bit off the topic of the original thread, better to
> spin this off. I'll reply to the DnD bits in another email.
>
> On Fri, Apr 17, 2015 at 9:50 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>> On Thu, Apr 16, 2015 at 12:55:31PM +0200, Carlos Garnacho wrote:
>>> Hey Jonas,
>>>
>>> On Thu, Apr 16, 2015 at 10:15 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>>>
>>> <snip>
>>>
>>> >
>>> > I'd have to agree on that it doesn't seem like the best thing to let the
>>> > compositor choose the preferred action. Having it apply compositor
>>> > specific policy given what the keyboard state or similar will probably
>>> > never work out very well, given that for example what modifier state
>>> > means what type of action is very application dependent.
>>> >
>>> > On the other hand, I'm not sure we can currently rely on either side
>>> > having keyboard focus during the drag. In weston the source will have the
>>> > focus because starting the drag was done with a click which gave the
>>> > surface keyboard focus implicitly, but what'd happen if the compositor
>>> > has keyboard-focus-follows-mouse? We could probably say that drag implies
>>> > an implicit grab on another device on the same seat to enforce no
>>> > changing of keyboard focus, but not sure that is better.
>>>
>>> In gtk+/gnome we currently have the following keybindings active during DnD:
>>>
>>> - Cursor keys move the drag point, modifiers affect speed
>>> - Esc key cancels drag
>>> - Modifiers alone pick an action from the offered list
>>>
>>> So ok, the latter is dubious to punt to compositors, but there's
>>> basically no other choice with the 2 first ones.
>>>
>>> More generally, I have the opinion that compositors grabs should
>>> behave all consistently, as in:
>>>
>>> - Ensuring clients reset all input state (we eg. don't cancel ongoing
>>> touches when xdg_popup/dnd/... grabs kick in)
>>
>> What does "client reset all input state" mean? What state can a client
>> reset?
>
> Let's expand on that example, maybe far-streched, but certainly possible:
> - I'm manipulating a client window with 2 fingers on the touchscreen
> (say zooming an image)
> - Any other interaction on the client makes it pop up an xdg_popup
> (say a third touch, a key combo, or the pointer)
> - Q: what happens with the two first touches?
>
> Ideally, these touches should be "cancelled" on the first surface
> (wl_touch.cancelled seems to be per client, not per-surface though),
> and stay non-reactive within the grab, so they wouldn't trigger
> anything unintended (they're implicitly grabbed on another surface
> after all)
>

The other option is to keep the implicit grab for those touches. You
could just keep those two fingers grabbed to the old surface until
released but if the old surface wants some other input there is no way
to tell. The user can, however, potentially get rid of the popup/dnd
and continue the operation that was started in the previous grab,
presumably. Which may not make that much sense with a modal popup but
might actually work with dnd.

Thanks

Michal