clipboard: Merge import from CVS

2 files changed, 162 insertions, 0 deletions

diff --git a/clipboard/clipboard-extensions.txt b/clipboard/clipboard-extensions.txt
new file mode 100644
index 0000000..ceed6ca
--- /dev/null
+++ b/clipboard/clipboard-extensions.txt
@@ -0,0 +1,39 @@
+  
+  Selection target _NET_MAX_SELECTION_SIZE
+
+  When a client encounters target _NET_MAX_SELECTION_SIZE in
+ SelectionRequest event, it should use its value as a limit for the
+ following targets in the same request (i.e. the request should be of type
+ MULTIPLE). The
+ _NET_MAX_SELECTION_SIZE target should be always the first target in the
+ MULTIPLE request.
+
+  The target _NET_MAX_SELECTION_SIZE is a side-effect target, as described
+ in ICCCM section 2.6.3. When handling this target, the matching property on
+ the requestor window should be of type XA_INTEGER, format 32, with 2
+ elements.
+
+  If the selection owner's connection to the X server is local, the first
+ element is used as the limit, otherwise the second element is used as the
+ limit. A local connection is identified by a value of XDisplayString() with
+ the first character ':', for example, ":0.0". A value of -1 for either
+ element means no limit.
+
+  The value should limit the sum of the sizes in the request, not separately
+ each of them. The client should reject subsequent targets if they would
+ cause the total amount of data transferred for all targets to exceed the
+ limit. Note that there is no requirement that if one target is rejected,
+ all other targets will be rejected or all that subsequent targets will be
+ rejected.
+
+  Clients are not required to limit the data size precisely to the given
+ value. If the computation of the data size would be expensive for the
+ client, a certain reasonable inaccurancy is allowed. In other words, if the
+ client for various reasons doesn't know exact size of the data to be
+ transfered, it should try to estimate it, rather than transfering data with
+ size that is possibly magnitudes larger.
+
+ The intent of this target is to avoid unwanted large transfers, so it
+ should be requsted only by xclipboard-like tools. They should use a request
+ of type MULTIPLE with _NET_MAX_SELECTION_SIZE as the first target in the
+ MULTIPLE request, with the requested target(s) after it.
diff --git a/clipboard/clipboards.txt b/clipboard/clipboards.txt
new file mode 100644
index 0000000..610083e
--- /dev/null
+++ b/clipboard/clipboards.txt
@@ -0,0 +1,123 @@
+Historically, X clients have not handled cut-and-paste in a consistent
+way, leading users to believe that X doesn't even have a working
+clipboard. This isn't really accurate; there is a conventional
+behavior, somewhat standardized in the ICCCM. But many apps don't
+follow the conventional behavior.
+
+X has a thing called "selections" which are just clipboards,
+essentially (implemented with an asynchronous protocol so you don't
+actually copy data to them). There are three standard selections
+defined in the ICCCM: PRIMARY, SECONDARY, and CLIPBOARD.
+
+The ICCCM defines these as follows:
+
+  "The selection named by the atom PRIMARY is used for all com-
+  mands  that take only a single argument and is the principal
+  means of communication between clients that use  the  selec-
+  tion mechanism.
+
+  The selection named by the atom SECONDARY is used:
+
+  o   As  the second argument to commands taking two arguments
+      (for example, "exchange  primary  and  secondary  selec-
+      tions")
+
+  o   As  a  means  of  obtaining data when there is a primary
+      selection and the user does not want to disturb it
+
+  The selection named by the atom CLIPBOARD is  used  to  hold
+  data  that  is  being  transferred between clients, that is,
+  data that usually is being cut and then pasted or copied and
+  then  pasted."
+
+In addition, the ICCCM has a thing called "cut buffers" which most
+clients no longer support.
+
+There are two historical interpretations of the ICCCM:
+
+ a) use PRIMARY for mouse selection, middle mouse button paste, and
+    explicit cut/copy/paste menu items (Qt 2, GNU Emacs 20)
+ b) use CLIPBOARD for the Windows-style cut/copy/paste menu items;
+    use PRIMARY for the currently-selected text, even if it isn't
+    explicitly copied, and for middle-mouse-click (Netscape, Mozilla,
+    XEmacs, some GTK+ apps)
+
+No one ever does anything interesting with SECONDARY as far as I can
+tell.
+
+The current consensus is that interpretation b) is correct. Qt 3 and
+GNU Emacs 21 will use interpretation b), changing the behavior of
+previous versions.
+
+The correct behavior can be summarized as follows: CLIPBOARD works
+just like the clipboard on Mac or Windows; it only changes on explicit
+cut/copy. PRIMARY is an "easter egg" for expert users, regular users
+can just ignore it; it's normally pastable only via
+middle-mouse-click.
+
+The rationale for this behavior is mostly that behavior a) has a lot
+of problems, namely:
+
+ - inconsistent with Mac/Windows
+ - confusingly, selecting anything overwrites the clipboard
+ - not efficient with a tool such as xclipboard
+ - you should be able to select text, then paste the clipboard
+   over it, but that doesn't work if the selection and
+   clipboard are the same
+ - the Copy menu item is useless and does nothing,
+   which is confusing
+ - if you think of PRIMARY as the current selection,
+   Cut doesn't make any sense since the selection simultaneously
+   disappears and becomes the current selection
+
+Application authors should follow the following guidelines to get
+correct behavior:
+
+ - selecting but with no explicit copy should only set PRIMARY,
+   never CLIPBOARD
+
+ - middle mouse button should paste PRIMARY, never CLIPBOARD
+
+ - explicit cut/copy commands (i.e. menu items, toolbar buttons)
+   should always set CLIPBOARD to the currently-selected data (i.e.
+   conceptually copy PRIMARY to CLIPBOARD)
+
+ - explicit cut/copy commands should always set both CLIPBOARD and
+   PRIMARY, even when copying doesn't involve a selection (e.g. a
+   "copy url" -option which explicitly copies an url without the
+   url being selected first)
+
+ - explicit paste commands should paste CLIPBOARD, not PRIMARY
+
+ - a selection becoming unselected should never unset PRIMARY
+
+ - possibly contradicting the ICCCM, clients don't need to support
+   SECONDARY, though if anyone can figure out what it's good
+   for they should feel free to use it for that
+
+ - cut buffers are evil; they only support ASCII, they don't 
+   work with many clients, and they require data to be 
+   copied to the X server. Therefore clients should avoid 
+   using cut buffers and use only selections.
+
+Apps that follow these guidelines give users a simple mental model to
+understand what's going on. PRIMARY is the current selection. Middle
+button pastes the current selection. CLIPBOARD is just like on
+Mac/Windows. You don't have to know about PRIMARY if you're a newbie.
+
+I don't think there's a sane mental model if we collapse everything
+into PRIMARY and ignore clipboard, see rationale above.
+
+A remaining somewhat odd thing about X selections is that exiting the
+app you did a cut/copy from removes the cut/copied data from the
+clipboard, since the selection protocol is asynchronous and requires
+the source app to provide the data at paste time. The solution here
+would be a standardized protocol for a "clipboard daemon" so that apps
+could hand off their data to a daemon when they exit. Or
+alternatively, you can run an application such as xclipboard which
+constantly "harvests" clipboard selections.
+
+References:
+ - the ICCCM, obviously
+ - http://www.xfree86.org/~keithp/talks/selection.ps
+ - http://www.jwz.org/doc/x-cut-and-paste.html