Clipboard and selection in wayland.

[Yichao Yu]

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