Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!dsg.csc.ti.COM!Kimbrough From: Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) Newsgroups: comp.windows.x Subject: Cut-and-paste Message-ID: <2796138891-8202615@Sierra> Date: 9 Aug 88 17:14:51 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 23 > So I say 'Cut cut buffers out of X -- and the rest'. Who would argue? I'll pick up the gauntlet. Actually, I agree with you -- the semantics of cut'n'paste is a client function. In fact, it's not really accurate to say that cut buffers are "in" X. The most you can say along this line is that the X protocol predefines the atoms PRIMARY, SECONDARY, CUT_BUFFER_0, ... CUT_BUFFER_7. However, the meaning and use of these atoms are left completely undefined. Certainly, cut'n'paste, as it is commonly known, is a user-initiated operation. That is, it must have *some* user interface. Specifically, the clients participanting in the operation (the cuttee and the pastee) are addressed by the user via their user interfaces: "Cut from here and paste to there". Since the participant clients are sharing an X server and since X provides a client channel that is independent of the communications hw/sw layers, it's eminently practical to use the server as the intermediary in cut'n'paste. That is, cuttee sends a message to the server to store the cut info, pastee sends a message to the server to retrieve the cut info. That is how the PRIMARY, SECONDARY, CUT_BUFFER_0, ... CUT_BUFFER_7 property atoms are intended to be used (although even this is merely a well-known inter-client convention and not a "feature" of X). But clients are responsible for defining the user gesture to perform the cut/paste, for figuring out exactly what info is to be cut, and for figuring out exactly what is to be done with the cut info when it is retrieved.