Clipboard and selection in wayland.

[Yichao Yu]

On Tue, Mar 12, 2013 at 7:19 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> On Tue, Mar 12, 2013 at 12:51 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> On 03/11/2013 07:56 PM, Yichao Yu wrote:
>>
>>> It may depends on how you define selecting but the point here is the
>>> content you start dragging should never clear the current PRIMARY
>>> selection (use x11 name to avoid ambiguity), e.g. if you drag the
>>> flower in the weston dnd demo, that shouldn't change what you are
>>> going to middle-button paste next.
>>
>>
>> That is interesting but I have not seen any real api's that do that. In all
>> cases they change the selection to the item being dragged (just tried this
>> on various file managers including Windows, and "drag" of an icon always
>> leaves it selected so that Ctrl+C copies it, and I believe anything that
>> changes what Ctrl+C will copy should also change what middle-button-paste
>> does. However I do think it is ok to be able to distinguish these
>> selections.
>
> Examples of being dragged but not causing a selection (basically
> anything that cannot be selected or should not be put in primary
> selection),
> Reorder menu items' order by dragging (or other UI elements that makes
> no sense to select, including the flowers in dnd-demo).
> Pure images (e.g. dragging from kscreenshot to pastebin applet.)
> Dragging window across desktop on a pager applet.
> Dragging tag from one window to another window (e.g. chromium.)
> etc...
>
>>
>> My primary concern is that applications be strongly encouraged to treat
>> middle-button-click and a "drop" the same, in that exactly the same data is
>> accepted and it works exactly the same in both cases. This is best done by
>> making the api shared so programs are encouraged to do the same thing.
>>
>> What I really am trying to say is that on a range of "similarity" the 3 apis
>> should be something like this:
>>
>>    cut&paste .............................. middle-button-paste .. dnd
>
> middle-button-paste and dnd sometimes shares the same source (which
> normally means selecting before dragging) but that's not always true.
>
>>
>> What should be avoided is the X mistake of making dnd be the "different"
>
> X have actually done this right.
>
>> one, which is why there are so many broken programs that confuse cut & paste
>
> They were confused because there wasn't a standard of the X Selection
> to use for these two, after the selection is made, all programs works
> well (and I'm not aware of any program still having the problem). So
> as long as we do not mix the three together, no one will be confused.
>
>> and middle-button-paste. Everything would be much better if all those
>> programs instead confused dnd and middle-button paste.
>
> That would be a world as terrible, especially if it is limited by the
> protocol and cannot be fixed.
>
>>
>> Mostly this means that the api for the target to retrieve the data for dnd
>> and for middle-button-paste should be IDENTICAL (except for an integer
>
> As I have mentioned above, there are lots of cases where starting a
> drag shouldn't cause a selection (or the item being dragged make no
> sense to be selected at all)
>
>> saying "which"), and the source should be able to set the data with
>> identical api's, including the ability to say that the selection and drag &
>> drop are the same data and thus only set it once.
>>

I have just had another look at the current selection-related
protocol. Right now there is only a ::selection event and a
::set_selection request for each wl_data_device. Since the name is
"selection" instead of "clipboard" and in fact I cannot find anywhere
in the protocol that mentions "clipboard", is it the clipboard,
instead of selection, that is not currently supported by the wayland
protocol? So should we just add a ::clipboard event and
::set_clipboard request to wl_data_device and leave the selection
request/event for "selection" (x11's PRIMARY selection or
middle-button-paste)?