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

[Giulio Camuffo]

2013/4/4 Kristian Høgsberg <krh at bitplanet.net>

> On Thu, Apr 4, 2013 at 1:54 PM, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
> > 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.
>
> I'm not sure if this is what Bill is getting at, but there is a
> problem with just unconditionally triggering motion bindings.  If
> you're moving or resizing a window and move the pointer to the corner,
> you don't want to make that trigger an expose effect or such.
>

That's true, but it doesn't require any client intervention, and it can be
easily dealt with by the shell. Possibly by the shell only: not sending the
binding when e.g. there is a pointer grab active would mean that having a
popup open would inhibit the binding.

Giulio


> Kristian
>
> > 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.
> >>>
> >>>
> >
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130404/cd847c7d/attachment-0001.html>