[PATCH weston] compositor: add a mouse motion binding type

[Giulio Camuffo]

There is no protocol for the client to tell the server if it used a motion
event.
But even if there was i don't think it should. The event is still delivered
to the client, it isn't eaten, so the client can still do whatever it
wants, but what's more important is that no client should change the shell
behaviour.
Right now, in X, if a client has a popup menu open you cannot trigger
effects like your wm implementation of exposè.
This is bad and should not happen, even if the menu is under the corner
which triggers the effect.

Giulio


2013/4/4 Bill Spitzak <spitzak at gmail.com>

> No this is the right message.
>
> The problem is that only the client knows "when the mouse hits an output
> corner" (or more accurately, the client is the only one that knows "the
> mouse is not pointing at something of mine that should do something other
> than a shell effect"). Therefore any "effect when the mouse hits an output
> corner" must not happen until the client confirms that the mouse at this
> location will cause this effect. As far as I can tell the "mouse moved
> binding handler" is part of the enter/exit code in the compositor, which is
> before client communication, this is wrong.
>
> Giulio Camuffo wrote:
>
>> Hmm, did you reply to the right mail? This has nothing to do with
>> resizing.
>>
>>
>> 2013/4/4 Bill Spitzak <spitzak at gmail.com <mailto:spitzak at gmail.com>>
>>
>>
>>
>>
>>     Giulio Camuffo wrote:
>>
>>         when a mouse is moved the binding handler is called, passing it
>> the
>>         mouse position and the timestamp. a shell plugin can use this to
>>         activate an effect when the mouse hits an output corner.
>>
>>
>>     Any preview of resize must be after the client tells the compositor
>>     that it will not use the mouse for some other purpose at that point.
>>
>>     If the compositor is able to force certain positions to be resize
>>     then either the "resize edges" are unattractively thick, or that it
>>     is very hard to grab the resize, or the preview of resize is
>>     inconsistent because the client has to do it for any internal parts
>>     that resize.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130404/9511a205/attachment-0001.html>