[RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Michal Suchanek]

Hello,

On 20 February 2016 at 01:31, Carlos Garnacho <carlosg at 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.

> +    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.

IMHO the fact that the application receives ANY input event suffices.
eg. a pointer entry event.

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.

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.

There are point-to-type and click-to-type keyboard focus models which
should be both supported by the primary selection protocol.

Thanks

Michal