Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.windows.x Subject: Re: CUTBUFFERS too small Message-ID: <2748@auspex.auspex.com> Date: 19 Dec 89 23:49:35 GMT References: <1942@odin.SGI.COM> Organization: Auspex Systems, Santa Clara Lines: 86 >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 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" (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.