Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!ANDREW.CMU.EDU!wjh+ From: wjh+@ANDREW.CMU.EDU (Fred Hansen) Newsgroups: comp.windows.x Subject: Re: CUTBUFFERS too small Message-ID: Date: 11 Dec 89 19:39:55 GMT Sender: root@athena.mit.edu (Wizard A. Root) Organization: The Internet Lines: 112 Excerpts from internet.xpert: 14-Nov-89 Re: CUTBUFFERS too small Phil Karlton@bloom-beaco (1619) > > In article , 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