On Thu, Jan 07, 2016 at 01:15:41PM -0500, Lyude wrote: > On Thu, 2016-01-07 at 10:37 +0100, Michal Suchanek wrote: > > 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. > I knew I was missing something in this. So, that's basically what it's like > now. > A client should be able to expect to get a request the first time something > gets > set in the primary selection. So, it is basically the same as X. I'll make > sure > to clarify this in the description.
they way I read the current protocol, you're planning on this: the receiving client gets a selection manager and a selection device, but there is no way of requesting the selection, you simply get the event whenever a source sets it. the client needs to hold this until a paste action happens, handling all cancelled events until then. that seems inefficient, and potentially leaks information since you know when the client selected something. what I'm missing is a request on the selection device that says "gimme the offer now", followed by the selection_offer event. unless you're intending to make the get_primary_selection_device() to be that request, i.e. a client should issue this request in response to the middle click. That works, I think, but it needs to be documented. Cheers, Peter > > > > > 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 > -- > Cheers, > Lyude > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
