Todd Showalter wrote:
On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk <[email protected]> wrote:
A compositor could just drop events that aren't over a focused window,
and it would solve Todd's problem, unless he's also expecting to be
able to scroll things without hovering over them.
My problem is that I expect one of two cases:
1) all focus follows the pointer (this is what I prefer)
2) click to focus
I can live with either, though I vastly prefer
focus-follows-pointer. The problem in OSX is that it's this broken
mushing of the two systems together; scroll wheel focus follows the
pointer, keyboard is click-to-focus.
I agree that is exactly what is wrong on OS/X.
Besides point-to-type and click-to-type there are a zillion other
possibilities, which are unexplored because current window systems force
the focus navigation to be part of the shell. An example would be that
the keyboard focus moves to the pointer window on a mouse-wheel scroll,
which would actually solve the OS/X problem you describe.
I believe Wayland can allow focus navigation to be the client's
responsibility. The client can decide whether it is point-to-type or
click-to-type, and also lots of other possibilities. This is done with
the following requests:
1. Take keyboard focus. This only works if the client has keyboard or
pointer focus.
A client that wants click-to-type grabs the keyboard focus on clicks. It
can also grab it on other events, like the scroll wheel. Also whether
the "focus click" can push buttons is left for the client to decide.
A client that wants point-to-type grabs the keyboard focus on mouse
enter, or on movement to some active area.
2. Take pointer focus. This only works in response to a
keyboard-focus-in, or if they client already has pointer focus. The
pointer is moved by the shell to point at some location in the surface
(or to a rectangle provided in the request).
The take-pointer-focus is so that a point-to-type client can respond to
keyboard focus events the shell produces by putting itself in a
consistent state where the pointer points at it. The primary purpose is
so a new window can popup with keyboard focus. Note this is NOT "focus
stealing" because the shell has to give the client keyboard focus, so
any solution to focus stealing for click-to-type works for this, too.
3. Raise. Wayland does this already, but it is vitally important that
surfaces only raise when the client requests it. This allows the client
to decide to take focus with or without raising.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
