On Tue, Mar 12, 2013 at 7:19 PM, Yichao Yu <yyc1...@gmail.com> wrote: > On Tue, Mar 12, 2013 at 12:51 PM, Bill Spitzak <spit...@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)? _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
