dshr@SUN.COM (David Rosenthal) (11/10/89)
The use of CUTBUFFERS is strongly deprecated by the ICCCM. None of your proposed work-arounds are acceptable. Please use the selection mechanism instead. It has full provision for the transfer of large amounts of data between applications. In particular, applications wanting to solve the two problems you point out (data available after client death, and history available) should use the CLIPBOARD, and run a clipboard client that maintains a history of previous clipboard contents. David.
wjh+@ANDREW.CMU.EDU (Fred Hansen) (11/13/89)
Please use the selection mechanism instead. It has full provision for the transfer of large amounts of data between applications. In particular, applications wanting to solve the two problems you point out (data available after client death, and history available) should use the CLIPBOARD, and run a clipboard client that maintains a history of previous clipboard contents. What exactly is the recommended ICCCM scheme? In particular, what is the relationship of CLIPBOARD and PRIMARY? Should a client that takes ownership of PRIMARY also take ownership of CLIPBOARD? Should a client that wants the latest cut value check the TIMESTAMP value from each of PRIMARY and CLIPBOARD? Fred Hansen
karlton@sgi.com (Phil Karlton) (11/15/89)
In article <cZLTNtq00VsPIsRJg9@andrew.cmu.edu>, wjh+@ANDREW.CMU.EDU (Fred Hansen) writes: > What exactly is the recommended ICCCM scheme? In particular, > what is the relationship of CLIPBOARD and PRIMARY? The notions of the CLIPBOARD and PRIMARY selections are independent. The CLIPBOARD is intended to be used for those objects that have been deleted (or copied to a trash bin, etc.). The PRIMARY selection is for those objects that have been merely selected, but no information deleting action has taken place. The client that wants the latest cut value should get that from the CLIPBOARD. A "paste" operation is a typical reason to do this. Other than when a clipboard client is being used, usally there is no representation on the screen of the object that is referenced by the CLIPBOARD. The client that wants to get the current value of an object (or some attribute of the current object) would get that from the PRIMARY selection. A "copy" operation is a typical reason to do this. Almost invariably there will be some highlighting on the screen of the object that is referenced by PRIMARY > Should a > client that takes ownership of PRIMARY also take ownership > of CLIPBOARD? Only at the point that the user executes some sort of "delete" or "cut" operation. > Should a client that wants the latest cut value > check the TIMESTAMP value from each of PRIMARY and > CLIPBOARD? No. The latest "cut value" should always be in CLIPBOARD. PK -- Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039
wjh+@ANDREW.CMU.EDU (Fred Hansen) (12/12/89)
Excerpts from internet.xpert: 14-Nov-89 Re: CUTBUFFERS too small Phil Karlton@bloom-beaco (1619) > > In article <cZLTNtq00VsPIsRJg9@andrew.cmu.edu>, wjh+@ANDREW.CMU.EDU > (Fred Hansen) writes: > > What exactly is the recommended ICCCM scheme? In particular, > > what is the relationship of CLIPBOARD and PRIMARY? > > The notions of the CLIPBOARD and PRIMARY selections are independent. > The CLIPBOARD is intended to be used for those objects that have been > deleted (or copied to a trash bin, etc.). The PRIMARY selection is for > those objects that have been merely selected, but no information > deleting action has taken place. > > The client that wants the latest cut value should get that from the > CLIPBOARD. A "paste" operation is a typical reason to do this. > Other than when a clipboard client is being used, usally there is no > representation on the screen of the object that is referenced by the > CLIPBOARD. > > The client that wants to get the current value of an object (or some > attribute of the current object) would get that from the PRIMARY > selection. A "copy" operation is a typical reason to do this. Almost > invariably there will be some highlighting on the screen of the object > that is referenced by PRIMARY > > > Should a > > client that takes ownership of PRIMARY also take ownership > > of CLIPBOARD? > > Only at the point that the user executes some sort of "delete" or > "cut" operation. > > > Should a client that wants the latest cut value > > check the TIMESTAMP value from each of PRIMARY and > > CLIPBOARD? > > No. The latest "cut value" should always be in CLIPBOARD. Thanks to Phil Karlton for a very complete reply. Let me try to translate this reply into a model I am familiar with so I can try to examine it more closely. There are four user operations: Select. Choose a piece of the text or image. Copy. Make a copy of the selected text into a hidden area. Cut. Same as copy, but also delete the original. Paste. Insert a copy of the item from the hidden area. To move text from place to place, the user Selects it, does a Cut, Selects the destination point, and does a Paste. To make multiple copies is the same except that Copy is used instead of Cut. X is intended to be policy free, so how do I map the above operations onto the ICCCM's PRIMARY and CLIPBOARD? (I do not claim that CUT_BUFFER0 is any better than what can be done with the other two. I omit it for simplicity.) Question 1. What to do when the user does a Select operation? If the user is accustomed to applications that utilize PRIMARY he or she may expect the Select operation to put the operand into PRIMARY. This will be contrary to the expectations of other users who expect things to go into the hidden area only for explicit operations. There is a further problem: if the user selects something to move and then double mouses at the destination the destination may be non-zero length. It might look to the application like another Select operation so a piece of the destination would be moved or copied instead of the intended source. This problem is less severe in systems with two different kinds of Select operations. (In ATK, the lowest levels do not learn when the user has Selected something, so ATK cannot currently grab PRIMARY when a Select is done.) Question 2. What to paste. If an application wants to participate in the ICCCM world, what should it do when the user selects Paste? should the value be taken from PRIMARY or CLIPBOARD? Some applications may implement only one or the other, so how is a general application expected to do the general operation of getting the item that the user "expects" to be pasted for a paste operation. It seems to me that if both PRIMARY and CLIPBOARD exist the application has to check the timestamps of each and take the more recent one. Otherwise how is the user to cut/copy/paste between applications? It is unfortunate that this scheme requires a fair number of interprocess swaps between server and client before beginning the paste. Question 3. What does a CLIPBOARD client do? The clipboard client is supposed to retain values that have been sent to the clipboard. This way an application can cut something which will remain accessible even after the application exits. It is part of the elegance of the selection mechanism, however, that selection owners may respond to multiple different targets, STRING, BITMAP, ODIF, ... How does the clipboard client choose one of these to ask for and retain? If it chooses STRING, then when the clipped value is a bitmap the clipboard will not retain it. The right answer is probably some overall data stream like ODIF or TIFF which can represent multiple different types. In a subsequent message I'll describe how ath Andrew ToolKit (ATK) has answered the above questions so it can participate in the ICCCM arena. Fred Hansen
karlton@sgi.com (Phil Karlton) (12/13/89)
In article <IZV0_=e00VsPI5g4dr@andrew.cmu.edu>, wjh+@ANDREW.CMU.EDU (Fred Hansen) writes: > Thanks to Phil Karlton for a very complete reply. Apparently not complete enough. > Let me try to translate this reply into a model I am familiar with > so I can try to examine it more closely. There are four user operations: > > Select. Choose a piece of the text or image. Repeating myself: the user interface should be highlighting the selected object on the screen in some manner. > Copy. Make a copy of the selected text into a hidden area. No. The copy operation operates directly on the selected object (text). There is no hidden area. Note that attributes other than merely the contents of the selected object may also be of interest, e.g. the font, the color, or size. Assert ownership of the PRIMARY selection. > Cut. Same as copy, but also delete the original. How about: Remove the object from its container and from the screen. Remember the object and its attributes and assert ownership of the CLIPBOARD. The object can be forgotten when the ownership of CLIPBOARD is lost. One can think of the object as residing in the "hidden area", but it may only be hidden if no clipboard client exists. > Paste. Insert a copy of the item from the hidden area. Sort of. Copy the result of getting the value of CLIPBOARD into the current insertion point. > To move text from place to place, the user Selects it, does a Cut, > Selects the destination point, and does a Paste. To move something I would hope that the user would merely select the object to move, indicate the destination and invoke the Move command. (Some user interfaces may even do the operation as an infix command; i.e., a mode is entered when "move" is invoked such that the next use of the mouse is automatically the destination. This kind of user interface can simplify the syntax. A copy operation is similar, it's just that the application doesn't cause the original to be deleted. > To make multiple > copies is the same except that Copy is used instead of Cut. Or copy is invoked multiple times. One of the disconnects seems to be that people are expecting that only the Mac style of user interface will be used. The whole notion of a clipboard to carry information from one application to another arose because originally only one application could run at a time, and the only way to transfer data was through some intermediary. Having the application directly deal with the data in other applications can lead to a simpler, more effective user interface. > X is intended to be policy free, so how do I map the above > operations onto the ICCCM's PRIMARY and CLIPBOARD? > (I do not claim that CUT_BUFFER0 is any better than what > can be done with the other two. I omit it for simplicity.) > Question 1. What to do when the user does a Select operation? > > If the user is accustomed to applications that utilize PRIMARY > he or she may expect the Select operation to put the operand into > PRIMARY. This does not parse for me. Nothing is put into PRIMARY. The application merely asserts ownership of the PRIMARY selection. > This will be contrary to the expectations of other users > who expect things to go into the hidden area only for explicit > operations. and nothing goes into the "hidden area". > There is a further problem: if the user selects something to move > and then double mouses at the destination the destination may be > non-zero length. It might look to the application like another Select > operation so a piece of the destination would be moved or copied instead > of the intended source. This problem is less severe in systems > with two different kinds of Select operations. Yes, the syntax (the buttons/motions/keys the user uses to effect some operation) for "copy" or "move" or "choose destination" has to be different than "make selection". > Question 2. What to paste. > If an application wants to participate in the ICCCM world, > what should it do when the user selects Paste? should the value > be taken from PRIMARY or CLIPBOARD? The value shoudl be taken from the CLIPBOARD selection. That is the semantic meaning of "paste" (as opposed to "copy"). > Some applications > may implement only one or the other, Right, that is policy. > so how is a general > application expected to do the general operation of getting the > item that the user "expects" to be pasted for a paste operation. Without some mind reading device, it is hard for the general application to execute a general operation that does what the user "expects". > It seems to me that if both PRIMARY and CLIPBOARD exist the > application has to check the timestamps of each and take the more > recent one. Otherwise how is the user to cut/copy/paste between > applications? It is unfortunate that this scheme requires a fair > number of interprocess swaps between server and client before > beginning the paste. See above. the sematics of the particular opeartion dictate the selection to be used. An application doesn't have to convert all of the selections and then guess which one to use. > Question 3. What does a CLIPBOARD client do? > > The clipboard client is supposed to retain values that have been > sent to the clipboard. This way an application can cut something > which will remain accessible even after the application exits. > It is part of the elegance of the selection mechanism, however, that > selection owners may respond to multiple different targets, STRING, > BITMAP, ODIF, ... How does the clipboard client choose one of these > to ask for and retain? If it chooses STRING, then when the clipped > value is a bitmap the clipboard will not retain it. The right answer > is probably some overall data stream like ODIF or TIFF which can > represent multiple different types. The clipboard client has some benefits and costs to the user. The benefits include 1) the user is afraid that the original "cutting" application will be disconnected from the X server and will not be able to answer questions about the "cut" 2) The clipboard client might maintain a history of "cut" objects and therefore be able to have some user interface allowing the user to restore something from the distant past. The costs include 1) All of the data that is ever cut, must be converted to all of the targets that somebody might ask. This could result in fairly substantial network traffic for an object that nobody will ever ask for. It is basically unproductive work. 2) The set of targets supported by the clipboard client will tend to be static. The attributes of data that has been cut and then wants to be pasted is limited to the imagination of the clipboard client implementor. It could easily get in the way of two more forward thinking clients. It is up to the system designer or user to decide which set of concerns is more important. PK -- Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039
guy@auspex.auspex.com (Guy Harris) (12/20/89)
>One of the disconnects (You didn't work for AT&T, or work heavily with AT&T people, at any point, did you? :-)) >seems to be that people are expecting that only the Mac style of user >interface will be used. The whole notion of a clipboard to carry >information from one application to another arose because originally >only one application could run at a time, and the only way to transfer >data was through some intermediary. Having the application directly >deal with the data in other applications can lead to a simpler, more >effective user interface. If you're talking about the difference between a set of operations such as "cut", "non-destructive cut" (which is what I suspect Fred means by "copy"), and "paste" vs. a set of operations such as "move" and "copy", I'd say that's a matter of taste. Having used EMACS-flavored editors (of which Andrew's "ez" happens to be one) for several years, my brain would have to shift gears a bit to exclusively use the latter set of operations (that is, operations where data transfer operations take both an explicit source and an explicit destination as operands, rather than having a clipboard/kill buffer/whatever as an implicit operand). I might use an operation such as you describe in >To move something I would hope that the user would merely select the >object to move, indicate the destination and invoke the Move command. ; in fact, I do use an operation similar to that in Sunview, namely the "Stuff" operand, which is, I think, similar to what you seem to mean by "copy" - it takes the currently selected text and inserts it into the tty input stream of the shelltool in whose window the "Stuff" operation is being performed. (Sunview also has a "Put then Get" operation which is, I think, similar.) However, I wouldn't want it to be the *only* operation of that sort; I'd want a "cut"-like and a "paste"-like operation as well. (At one point I modified the Office Power word processor, which I'd originally constructed to have "move" and "copy" operations, to have "cut"/"non-destructive cut"/"paste" operations instead, because it simplified some aspects of the user interface.) If it is the intent that no X clients implement a "non-destructive cut" operation (which would, I think, be an operation that makes the CLIPBOARD selection refer to a copy of data from the application, said copy being in a "hidden place") I suspect you'll have a revolt on your hands; I certainly wouldn't find that acceptable. I suspect that was *not* the intent, though, and that the real problem lies elsewhere; namely, you and Fred may not have the same idea in mind for what an operation named "copy" would be. When you say >> Copy. Make a copy of the selected text into a hidden area. > >No. The copy operation operates directly on the selected object (text). >There is no hidden area. Note that attributes other than merely the >contents of the selected object may also be of interest, e.g. the font, >the color, or size. Assert ownership of the PRIMARY selection. I'm not sure whether you mean "non-destructive cut" or "make a copy of the selected text in another place in some application" by "copy". As indicated, I suspect Fred means the former, since that's what <ESC>w is generally bound to in Andrew (and in other EMACS-flavored editors). From what you've said, I think you may mean the latter; that may be the source of some confusion here. If we're talking about how Andrew should use the PRIMARY and CLIPBOARD selections, when the word "copy" is used, do not think of an operation that, say, places a copy of some data in another place in the same or a different document; the Andrew "copy" operation places it in an internal buffer for later use, for example with the "paste" operation. Given that, and given that the Andrew "cut" operation ("zap", or ^W)'s behavior should be, as you indicate: >How about: Remove the object from its container and from the screen. >Remember the object and its attributes and assert ownership of the >CLIPBOARD. The object can be forgotten when the ownership of CLIPBOARD >is lost. One can think of the object as residing in the "hidden area", >but it may only be hidden if no clipboard client exists. the Andrew "copy" (<ESC>w - "non-destructive cut") operation should "remember the object" being cut (along with its attributes, but given that this is Andrew I think that can be taken as a given), *NOT* remove it from the container (or the screen, obviously), and assert ownership of the CLIPBOARD.
guy@auspex.auspex.com (Guy Harris) (12/20/89)
>I'm not sure whether you mean "non-destructive cut" or "make a copy of >the selected text in another place in some application" by "copy". It appears, BTW, that the ICCCM itself means "non-destructive cut" by "copy"; from "2.6.1.3 The CLIPBOARD Selection": The selection named by the atom CLIPBOARD is used to hold data being transferred between clients, normally being "cut" or "copied", and then "pasted". ... ^^^^^^