On 7 January 2016 at 04:42, Jonas Ådahl <jad...@gmail.com> wrote: > On Wed, Jan 06, 2016 at 09:50:36PM -0500, Lyude wrote: >> Signed-off-by: Lyude <cp...@redhat.com> >> --- >> >> Notes: >> Changes since V2 >> * Bunch of grammatical/wording fixes from whot >> * Addition of wp_primary_selection_offer::end_offers, for marking the >> end of a >> list of mime type offers >> * selection_offers are no longer sent before an input event, and are >> sent at the >> first opportunity a client has to do a primary selection paste. This >> decision >> comes from a discussion with Jasper, where a couple of clients (such >> as emacs) >> were brought up that have their own bindings for primary selection >> pasting. >> Eventually I will probably work on adding some sort of paste_hint >> event to >> this so that the compositor can decide what keybinding triggers a >> primary >> selection paste, I agree with Jasper that it would be best to solve >> the issue >> of rebinding primary selection pastes after we have the basic protocol >> for >> primary selection worked out. > > Does this mean that the offer always comes on keyboard focus? Or pointer > focus? Or touch focus? Or does it come a user interaction of some kind? > And after that it may retrieve the primary selection at any point? Could > it not be done as request that is a response to an input event carrying > a serial, where the serial can be used to match the request to the > triggering user interaction. Or would that break some expectations of > the primary selection use case (i.e. retrieve not from a user > interaction)?
The primary selection expectation in X is that an application can retrieve it at any time. It has been pointed out that focus is not what it used to be in X and and hence is not useful for determining paste ability. Also the application should be responsible for determining what action (if any) triggers paste and it gives no useful information if the paste request is tied to an input event, anyway. However, the compositor can and should apply a policy to pastes and not send the paste offer to all applications as soon as a selection is set. One way to do that and preserve the feel of X primary selection is to send an offer once an application receives user input (event) after a selection was set. That way applications can decide which user action triggers a paste using application-specific bindings. As the offer is invalidated once new selection is set an application cannot get arbitrary pastes from the paste buffer without user action. If desired different non-default policy on pastes (event filters) can be applied to different applications to accommodate both paste managers that should receive paste offer as soon as selection is set and sandboxed applications that should not have access to the paste buffer. Thanks Michal _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
