On Mon, Nov 09, 2015 at 02:33:39PM -0800, Jason Gerecke wrote: > On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak <[email protected]> wrote: > > Having read this more carefully, the cursor scheme absolutely will not work. > > > > The main problem is that the client may want to choose a cursor for a tool > > based on the location at which it came into proximity. It cannot set this > > cursor until after it gets the proximity event. If this desired cursor is > > different than the one the tool currently has set then that incorrect cursor > > will be seen, at least briefly. > > > I'm afraid I don't understand what meaningful difference there is > between the scheme here and wl_pointer. As you point out, there is a > brief window of time when the incorrect cursor can be seen with _both_ > protocols. Its a simple result of the fact that a client _can't_ know > that it needs to change the cursor until _after_ it receives some kind > of focus event ('enter' or 'proximity_in'). I suppose the client could > provide a reference to the surface over which a particular > 'set_cursor' should take effect (and then have the compositor keep > track of all those references) but I'm sure that has its own issues. > > > A further problem is that there has to be an easy transition between clients > > that don't use the tablet api and those that do. Operation of gui widgets > > that work equally well with mouse or tablet should not change just because > > the client has decided to enable the tablet interface. The primary problem > > is that the pointer position must move to the last tablet tool positiion > > whether or not the client is using the tablet interface. This then means > > there cannot be more than one cursor (since they would be right atop each > > other). > > > While I absolutely agree that GUI widgets should work equally well > with a tablet as a pointer, the "primary problem" is not that the > pointer has to be moved; widgets can work just fine if they're aware > of the tablet protocol. The fundamental problem that prevents things > from "just working" is that tablets don't send wl_pointer events of > any kind. > > There's certainly a compatibility benefit to having the tablet > controlling the pointer, but it isn't always appropriate.
note that the protocol doesn't *prevent* a compositor from emulating wl_pointer events for tablet events. the weston implementation here doesn't do so because I think it's a bad idea (for the reasons you outlined anyway) but in theory nothing stops anyone from doing so. > Although you > can get away with it in the most common case of a non-display tablet > mapped to the entire desktop, it gets annoying _fast_ when a tablet > which is mapped to just a portion of the desktop (e.g. a display > tablet on a multi-head system) since you /don't/ generally want the > mouse cursor to move: you just want the UI elements you click on to > respond. Putting tablets into separate seats might be a solution to > this, but it seems like its ripe for causing other unintended problems > (e.g. clicking on a text box and then not being able to type since the > keyboard focus isn't associated with the same seat as the tablet). > > Leaving support for the tablet protocol up to the client gives me > pause, but its less frightening once you consider that practically any > non-toy application will be written with the aid of a toolkit. As long > as the toolkits do the right thing, so will applications built on > them. Its the same situation with touch: authors who don't use a > toolkit can write applications that don't function with a touchscreen, > but most applications will work fine since toolkits know they need to > handle wl_touch. > > > My recommendation: > > > > - Proximity-in jumps the cursor and pointer position to the location but > > does not change the cursor. It will however send proximity-in events to the > > client (it will also send proximity-out to other clients using the tablet > > interface, and normal wl_pointer exit events to clients not using the tablet > > interface). > > > > - Client should respond to proximity-in by setting the wl_pointer cursor to > > whatever is desired. Notice this is identical to how clients not using the > > tablet interface respond to wl_pointer::enter events. > > > > This will 'blink' still, as the current cursor is also possibly not equal to > > the desired cursor. This could be fixed, but if so the exact same fix must > > be done to enter events or you really are not solving anything. Also note > > that hiding the cursor is not acceptable, it will be perceived as a blink if > > the cursor was correct and near the location of the proximity-in. > > > Disagree with these two recommendations as outlined above. > > > - Proximity-in and enter events "freeze" the cursor at it's current > > location, and it does not move until the client sets the cursor image. > > > Wouldn't this alone solve the issue of the wrong pointer being > displayed for a split-second? I'm not sure if its the compositor's > place to "freeze" the cursor until a client responds (that sounds a > little dicey, especially with hung clients), but it could be an > interesting approach. freezing a cursor at a location makes the system look unresponsive as opposed to just one application not updating a cursor quickly enough. plus, if a client does not needing a cursor image for the tablet we may freeze the cursor and wait for a request that never comes. there's room for a wl_godot protocol, this is not it though :) Cheers, Peter _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
