On 10/08/2015 10:15 AM, Derek Foreman wrote:
On 07/10/15 07:41 PM, Jonas Ådahl wrote:
I think it would be nice to land this in the same release cycle (ie:
this one) as pointer confinement, because I think the two features
really go hand in hand.
Indeed. Relative pointer events are quite useless if you loose focus
almost immediately
Wrong. Relative pointer events are useful if the client has a grab, such
as when the user is holding the mouse button down. They thus don't loose
focus "almost immediately", they lose it when the user releases the
mouse button.
For instance they could be used to scroll a very tall popup menu as the
mouse hits the edge of the screen. Or to make a smooth drawing stroke
even if the path the user makes goes outside the screen.
If the client could also control where the cursor is drawn then this
would work even for clients that don't touch the screen edges. It would
be the nirvana of usefulness for toolkit authors. That is why I am still
really insistent that the proposed pointer lock have these TRIVIAL
modifications:
1. The cursor is not "frozen" during pointer lock, instead it is placed
at the "hint" position.
2. There is a type of pointer lock that is attached to a mouse-down
event and is lost when the mouse is released. The reason for this is
because a compositor will be much more likely to grant such a lock,
because it is easy for a user to get out of it no matter how misbehaved
a client is. Therefore clients can assume it will work.
I know this will get ignored, but I still don't understand why. My
changes are obvious and really useful. All I can think is that Jonas is
thinking of a single usage for games, and is failing to realize how
incredibly useful his pointer lock would be in many other cases.
Why are we passing a pointer object here instead of the seat? If a game
wants relative pointer data it'll likely not want absolute pointer data,
so why does it have to bind an absolute pointer (and receive events on
it?) before it can get the relative stuff it's actually going to use?
The client needs to know where the cursor actually is so it can start
the relative motion at the right place. So it will need to get absolute
positions. Also the button events are sent to the pointer.
Why not just allow the pointer to be bound as either/both serial and
absolute, and have each be a fully functional interface?
It needs to be able to see both the absolute and relative events without
a round trip. So it would keep both open and would just get duplicate
button events.
A simpler solution would be to just make the relative motion be another
event produced by wl_pointer, or to add extra fields to the motion
events. Not sure why that solution is ruled out, it seems to be allowed
when the protocol version changes. The overhead is trivial because the
absolute event is being sent anyway.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
