Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!arisia!sgi!shinobu!odin!sgi.com!karlton From: karlton@sgi.com (Phil Karlton) Newsgroups: comp.windows.x Subject: Re: CUTBUFFERS too small Message-ID: <1942@odin.SGI.COM> Date: 12 Dec 89 23:24:26 GMT References: Sender: news@odin.SGI.COM Reply-To: karlton@sgi.com Organization: Silicon Graphics, WorkGroup Products Division Lines: 168 In article , 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