<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 9:03 AM, Lyude <span dir="ltr"><<a href="mailto:cpaul@redhat.com" target="_blank">cpaul@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Signed-off-by: Lyude <<a href="mailto:cpaul@redhat.com">cpaul@redhat.com</a>><br>
---<br>
                                    Changes<br>
* Add new interfaces to replace reuse of wl_data_(source|offer)<br>
* Get rid of the selection changed event since we now have our own version<br>
  of wl_data_(source|offer), and clients can just assume destroyed events<br>
  indicate that their data in the primary clipboard has been replaced.<br>
* Get rid of summary on arguments, I noticed most of the official wayland<br>
  protocol doesn't actually use these, and they were mostly redundant<br>
  anyway.<br>
* s/selection_set/set_selection/<br>
* Add destructor requests for all interfaces<br></blockquote><div><br></div><div>I do not like the fact that a program has to create both a wl_primary_selection_offer and a wl_data_offer on any selection (yes it can defer the second one until the user starts a drag, but it still would be nice to reuse the same one for both). Still not a huge problem, like in many other cases the two proxies can be stuffed into the same higher-level api object.<br><br></div><div>Some assurance that the abilities of both will be kept identical would help, however. I don't want some data transfers to be impossible depending on whether the user does dnd or middle-click paste.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+    <request name="get_primary_selection_device"><br>
+      <description summary="primary selection device manager"><br>
<span class="">+        Singleton global object that manages the zwp_primary_selection_device_v1<br>
+        objects for each wl_seat.<br>
+      </description><br>
+      <arg name="id" type="new_id" interface="zwp_primary_selection_device_v1"/><br>
+      <arg name="seat" type="object" interface="wl_seat"/><br>
+    </request><br></span></blockquote><div><br></div><div>Also, looking at what happened to wl_pointer, it appears the design of Wayland is to not have any "singletons" except the globally-advertised objects. I'm not sure if this has any visible effects on your api because there is no actual state stored on the object, and you must already support creating more than one, but it might make sense to get rid of the words "Singleton global".<br><span class=""></span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
+  <interface name="zwp_primary_selection_device_v1" version="1"><br>
</span>+    <request name="set_selection"><br>
<span class="">+      <description summary="set the primary selection"><br>
+        Set the current contents of the primary selection buffer. This clears<br>
+        anything which was previously held in the primary selection buffer.<br>
+<br>
+        This request can only be used while the window is focused.<br>
+      </description><br>
</span>+      <arg name="source" type="object" interface="zwp_primary_selection_source_v1"/><br>
+    </request><br></blockquote><div><br></div><div>Please don't require the "window is focused". The rules used by the compositor to accept/reject these offers should be defined by the compositor (a possible rule is that the window either got a mouse click or a keystroke from the seat). Clicking in a window should never be required to cause focus/activate/raise by the low-level api, that is instead part of the desktop and client definition.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">+    <event name="selection_offer"><br>
+      <description summary="primary selection buffer is ready for reading"><br>
+        Sent when the client has permission to read from the primary selection<br>
+        buffer.<br>
+<br>
+        This event is sent whenever the client receives a middle click, and will<br>
+        be received by the client before the actual middle click event. While<br>
+        the compositor is free to bind this event to another input event (such<br>
+        as a keyboard shortcut), the client should always treat pastes from the<br>
+        primary selection as middle clicks. This is to ensure the behavior is<br>
+        identical to that of primary selection pasting in X.<br>
+<br>
+        It is up to the client to decide whether or not it is appropriate to<br>
+        read from the primary buffer and paste it's contents.<br>
+      </description><br>
</span>+      <arg name="offer" type="new_id" interface="zwp_primary_selection_offer_v1"/><br>
+    </event><br></blockquote><div><br></div><div>I think it would be better to send this to the client when it gets any focus from the seat, and also if the selection is changed while it has focus. Then the client is able to free to use any method to do the paste (though of course using the middle mouse is encouraged). Also means there is not redundant events if the user clicks the middle mouse many times (a lot of programs use the middle-mouse drag as a pan operation).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+    <event name="send"><br>
+      <description summary="send the primary selection contents"><br>
+        Request for the current primary selection contents from the client.<br>
+        Send the specified mime type over the passed file descriptor, then<br>
+        close it.<br>
+      </description><br>
+      <arg name="mime_type" type="string"/><br>
+      <arg name="fd" type="fd"/><br>
+    </event><br></blockquote><div><br></div><div>May want to point out that this can happen more than once (ie the middle mouse button is clicked more than once per set_selection).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+    <event name="cancelled"><br>
+      <description summary="request for primary selection contents was canceled"><br>
+        This primary selection source has been replaced by another primary<br>
+        selection source. The client should clean up and destroy this primary<br>
+        selection source.<br>
+      </description><br>
+    </event><br></blockquote><div><br></div><div>I would guess this event is also sent if the compositor refuses the set_selection request? <br><br></div></div></div></div>