On Mon, Aug 24, 2015 at 10:44:55AM -0700, Bill Spitzak wrote: > On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl <[email protected]> wrote: > > > > > 1. the pointer "attaches" to the UI element. > > > > One would create a lock region on the scroll handle. When enabled one > > would hide the cursor, create an identical cursor surface and add it as > > a subsurface positioning relative to the scroll handle. One would now > > listen for events from wl_relative_pointer, update the subsurface > > position and the scroll handle widget under it. When done, one would > > unlock the lock, destroy the subsurface, and reset the pointer cursor. > > During the moving, one would set the cursor position hint so when > > resetting the cursor position would be updated. > > > > This is the first sign that you have actually thought about this. However > you seem blind to the trivial solution. Here is my rewrite of the above > paragraph with the set_cursor_pos proposal: > > "One would create a lock region on the scroll handle. When enabled one > would now listen for events from wl_relative_pointer, update the cursor > position and the scroll handle widget under it. When done, one would unlock > the lock." > > This is the only way to guarantee the "attachment" effect. There is one > > unsolved issue which is that the cursor sprite and the subsurface might > > be visible at the same time, and we'd need some kind of "transaction" > > protocol to solve this. There has been ideas to have a "set_cursor_pos" > > but this method would never give us any guarantees about "attachment". > > > > WTF???. Your proposal is that the client draw a fake cursor in a subsurface > and setting that to some x,y position to move the cursor. I propose that > the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS! It is > impossible for "attachement" to be different between the two proposals!!!! > > All I can guess is that you think that there is going to be synchronization > between subsurface positioning and the surface image, but for some reason > such synchronization will be missing for set_cursor_pos. But why? The > cursor surface belongs to the locking client just as much as any > subsurface, so any rules for subsurfaces can be applied to it as well. I'd > also like to know why suddenly this is important, when you have repeatedly > claimed that avoiding latency is more important that sync image updating.
Not going to go down this road again. > > If the client wants to control the activation, it can simply request the > > lock exactly at the point it wants it to be activated. resize.c in > > weston is an example of this - it activates the lock on a pointer button > > event. > > > > This is great if it works, however I hope you realize that this will be the > ONLY way that any clients with small lock regions will turn on pointer > lock. Having to update the "activation region" for every widget on every > layout change is extremely bad, it will send large amounts of data to the > server for no reason, kind of like old X11 toolkits that sent every widget > as a subwindow. This was known to be a mistake back in the mid 80's when > lightweight widgets were added to x intrinsics. Requesting a lock as a response to a click sounds like a reasonable way to implement it to me. Jonas _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
