Hey, On Mon, Nov 16, 2015 at 8:04 PM, Daniel Stone <[email protected]> wrote: > Bill, > > On Monday, 16 November 2015, Bill Spitzak <[email protected]> wrote: >> >> There is a need to distinguish proximity-out from exit events. It is quite >> possible to move the stylus so that the focus enters another client without >> doing a proximity-out. Clients are interested in distinguishing these. > > > This is true, hence my suggestion. > >> >> I really feel the best method is to say a "seat" has a keyboard focus and >> a pointer focus, and let the stylus manipulate the pointer focus. Thus the >> client will get enter/exit events as the stylus is moved around above the >> tablet, and proximity in/out when it is moved toward/away from the tablet >> (it may also get a fake proximity-in event on enter). > > > Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a > huge mistake. From our point of view, this is a closed topic. > > We've been over it time and time again, we've seen the ways the alternate > model - though it seems attractive at first, which is why we did it for X11 > - fails, and we're not going back there. > >> >> I really feel the cursor stuff is a huge mistake. It adds lots of >> complexity for almost no actual gain. Witness how much code you had to add >> to toytoolkit to support it. It adds complexity to clients as the client has >> to pass which tool to subroutines for no reason other than to allow them to >> change the correct cursor. The clients cannot assume the tool has the >> "right" cursor and therefore they are required to have code to change it, so >> this removes no complexity from clients. It is also hugely inconsistent with >> how normal pointer enter events are handled in Wayland. > > > It's not 'no actual gain', it's integral to the model. > >> >> The only argument you had was that the cursor is more likely to be >> correct, so when the proximity-in event happens, the cursor that appears has >> a higher chance of being the same as the one the client sets and there will >> be less blinking. However this can be implemented by the compositor without >> any client api. Just have the compositor remember what cursor was used and >> set that as a guess on the enter event. The client can remain completely >> unaware of whether a cursor is remembered per-tool, or per-surface, or per >> tool*surface, or whatever. > > > The reason the protocol does not do this, is because when the cursor is > different, you go from the other-surface cursor, to the old new-surface > cursor, to the new new-surface cursor, very rapidly. It's ugly, and a > bandaid for clients not responding quickly enough.
It's probably worth pointing out that his concerns are moot, there is no blinking, or rather, has an easy solution in compositors. When a tool physically enters in proximity over a surface, the cursor should be effectively invisible, the client below it will emit wp_tablet_tool.set_cursor in response to proximity_in, and it will be set accordingly from the previous invisible state. If the tool moves across surfaces, the cursor won't be modified until the new focus surface calls wp_tablet_tool.set_cursor, just like it happens with wl_pointer.set_cursor and wl_pointer.enter. When the tool physically leaves proximity, the cursor would be made invisible, destroyed, or whatnot. Compositors may of course want to set a default cursor if the proximity_in happened outside a surface, so that there's something visible until the tool enters a surface, but this is easy enough to detect before even showing the cursor. AFAICS the only source of "blinking" would be compositors invariably setting a visible cursor before the client has an opportunity to do so, that sounds somewhat sloppy though. Cheers, Carlos _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
