wl_tablet draft v2

[Pekka Paalanen]

On Thu, 17 Jul 2014 15:58:17 -0400
Lyude <thatslyude at gmail.com> wrote:

> On Thu, 2014-07-17 at 11:48 -0700, Bill Spitzak wrote:
> > On 07/13/2014 12:17 PM, Lyude wrote:
> > 
> > > 	- proximity_out
> > > 	  Sent whenever the tool leaves the proximity of the tablet or moves
> > > 	  out of the client surface. When the tool goes out of proximity,
> > > 	  button release events are sent before the initial proximity_out
> > > 	  event for each button that was held down before the tablet tool left
> > > 	  proximity. Following that, an up event will be sent if the tool was
> > > 	  in contact with the surface of the tablet before it went out of
> > > 	  proximity. In addition, axis updates always come before a
> > > 	  proximity-out event.
> > > 	  Arguments:
> > > 		- Name: time
> > > 		  Type: uint
> > > 		  The time of the event with millisecond granularity.
> > 
> > This design has the same bug as current enter/leave events (and X 
> > enter/leave, too): a client has to look ahead in the events if it wants 
> > to update highlighting without blinking. Basically it needs to see if 
> > the leave event is due to the pointer entering another surface it owns. 
> > Right now the only solution is to use a look-ahead api to peek at the 
> > events after a leave to see if there is an enter there. I think it would 
> > be nice if such look-ahead was not required by the most basic functions 
> > of a toolkit.
> > 
> > To fix this, proximity-out needs some kind of indicator, such as a 
> > surface id, so that the client can know that a proximity-in event is 
> > coming, and thus it can ignore the proximity-out. If the new surface id 
> > is used (and zero for surfaces belonging to a different client) then 
> > only one event is needed: proximity-changed.
> 
> I see your point. I'll definitely add this in.

I don't think I see the problem.

I'm not sure what highlighting Bill is talking about, but
wl_pointer.enter/leave or wl_keyboard.enter/leave are not used for
"window active" highlighting, because xdg_shell has the proper "is
active" communication.

If he means something like widget highlighting while a tool is on
it, then it is all on the same wl_surface. If tool focus leaves the
wl_surface, it leaves the widget and usually also leaves the
window, too.

What would be a use case, where you might get blinking?

That is, what single thing would you be highlighting when input tool
focus is on any wl_surface the app has, but not highlighted when
input tool focus is not on any of the app's wl_surfaces?

If the higlighted item is related to where the input tool is, it
shouldn't be highlighted when the tool leaves that item. If the
item is highlighted because an action with the input tool on any
wl_surface may affect it, why remove the highlight when the input
tool leaves?


Thanks,
pq