Hi Michal, On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek <hramr...@gmail.com> wrote: > Hello, > > On 20 February 2016 at 01:31, Carlos Garnacho <carl...@gnome.org> wrote: > >> + >> + <description summary="Primary selection protocol"> >> + This protocol provides the ability to have a primary selection device to >> + match that of the X server. This primary selection is a shortcut to the >> + common clipboard selection, where text just needs to be selected in >> order >> + to allow copying it elsewhere. The de facto way to perform this action >> + is the middle mouse button, although it is not limited to this one. >> + >> + Clients wishing to honor primary selection should create a primary >> + selection source and set it as the selection through >> + wp_primary_selection_device.set_selection whenever the text selection >> + changes. In order to minimize calls in pointer-driven text selection, >> + it should happen only once after the operation finished. Similarly, >> + a NULL source should be set when text is unselected. >> + >> + wp_primary_selection_offer objects are first announced through the >> + wp_primary_selection_device.data_offer event. Immediately after this >> event, >> + the primary data offer will emit wp_primary_selection_offer.offer events >> + to let know of the mime types being offered. >> + >> + When the primary selection changes, the client with the keyboard focus >> + will receive wp_primary_selection_device.selection events. Only the >> client > > Why keyboard focus? > > Since paste is done mainly using mouse this has nothing to do with > keyboard focus.
Doing this so allows us to behave just the same than we do with the core protocol selection, slightly divergent protocols make sharing code harder. Conceptually, it also makes some sense to me. I argue that a logical "key" focus is needed in compositors, even on lack of wl_keyboard capabilities. Things that IMO make sense to tie together in this focus, per-seat are: - wl_keyboard focus - wp_text_input focus - focus por (possibly several) pads/buttonsets - clipboard selection - primary selection Of course these are only guidelines, and compositors may attempt to implement split foci for these. But still, selection should be tied to some definite focus, the other option is broadcasting, and I'd very much prefer not to do that. I may try to change the wording just to suggest it's loosely attached to keyboard focus though. > >> + with the keyboard focus will receive such events with a non-NULL >> + wp_primary_selection_offer. Across keyboard focus changes, previously >> + focused clients will receive wp_primary_selection_device.events with a >> + NULL wp_primary_selection_offer. >> + >> + In order to request the primary selection data, the client must pass >> + a recent serial pertaining to the press event that is triggering the >> + operation, if the compositor deems the serial valid and recent, the > > Why press event when it has an offer event to base the request on? > > There is no need to involve other unrelated events. IIRC The first protocol drafts attempted to limit the circumstances in which a client could read the primary selection. This is a change of approach. > > IMHO the fact that the application receives ANY input event suffices. > eg. a pointer entry event. Do you mean wl_pointer.enter should be enough to have the application read the primary selection? seems open to data leaks to me. This serial event is meant to check for user interaction rather than "any input event", so just focusing a client is not enough to have it retrieve the primary selection. > > Otherwise you are going to have very fragile protocol that often fails > because the application did not happen to receive whatever even is > requested by the protocol. Note that it just mentions a press event, but does no mention of the interface/device it comes from. It can be the serial received on wl_pointer.button, wl_keyboard.key, wl_touch.down, wp_tablet_tool.down, ... compositors should ideally check all input interfaces. > > It's even worse with the keyboard focus. If the event that triggers > the paste also triggers getting keyboard focus you are going to have > protocol open to all kind of ugly race conditions. If it does not > trigger getting the keyboard focus the paste just fails. Where do you see race conditions? Because focus is handled by the compositor before event emission, AFAICT the client would receive the following event sequence: --> wl_keyboard.enter wl_data_device.data_offer wl_data_offer.offer [...] wl_data_device.selection zwp_primary_selection_device_v1.data_offer zwp_primary_selection_offer_v1.offer [...] zwp_primary_selection_device_v1.selection wl_pointer.button (..., serial_you_want_to_pass) <-- zwp_primary_selection_offer_v1.receive (..., serial_you_want_to_pass) Which results in the expected action to take place. > > There are point-to-type and click-to-type keyboard focus models which > should be both supported by the primary selection protocol. I think both models agree in that the window will be focused after you clicked on it. Cheers, Carlos _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel