Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!wjh+ From: wjh+@andrew.cmu.edu (Fred Hansen) Newsgroups: comp.windows.x Subject: Re: R3 Selection Mechanism Message-ID: Date: 20 May 89 19:23:07 GMT Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Lines: 77 > How can I use the selection mechanism to implement ATK cut/paste > protocol? > Your question is not specific enough to provide a real answer. There > are probably lots of ways it could be implemented. But, without knowing > what all of the requirements are, it's probably impossible to know if > any of them are actually adequate. You haven't given any indication of > how non-ATK clients should interact with ATK clients at the UI or > semantic level, you haven't said anything about lifetime of the items. > There may be other things you haven't specified that are crucial (I > haven't thought about it too hard). OK. Let's make it simple and assume that there is no need for interaction between non-ATK clients and ATK clients. (I would like to relax this assumption in practice, but it ought to make the exercise easier.) Lifetime: There are eight cut buffers used in a ring organization. Once a value is placed in a buffer it remains alive until eight subsequent items have been placed in buffers or the window manager is terminated, whichever comes first. - - - - - - - - - - Description There is one set of eight cut buffers shared by all ATK applications and organized in a ring. Text or other items are stored in a cut buffer in an ASCII encoded form. The recipient of the value deciphers the ASCII to determine what variety of object it has received. (ASCII encoding permits arbitrary objects to be stored in a cutbuffer without the need for the sender to have routines to format the object differently for different receivers or for the receiver to have to make an initial handshake with the sender to find out what is available. The particular ASCII encoding is not a part of this exercise.) User interface operations: CUT - the cut ring is rotated and the new top element is replaced with the ASCII representation of the item or text that was selected (in the window where the operation is initiated). The item or text is removed from the original. COPY - the cut ring is rotated and the new top element is replaced with the ASCII representation of the item or text that was selected (in the window where the operation is initiated). The item or text remains unchanged in the original. PASTE - the contents of the top element of the cut ring are inserted at the end of the current selection (in the window where the operation is initiated). ROTATE-PASTE - the ring is rotated in the opposite direction from CUT or COPY and the new top element replaces the selection (in the window where the operation is initiated). - - - - - - - - - - A claim that seems to be implied for the X selection mechanism is that it should be used for communication of values the user wants to move from one X client to another. (Section 10.2 of the C language X interface manual states, "New applications are encouraged to share data by using selections.") An explicit claim on the comp.windows.x bboard was that the X selection mechanism does not affect the user interface. And yet, as far as I can see the X selection mechanism has little to offer in trying to implement the protocol described above. To repeat the statement of the exercise: Show how to utilize the X selection mechanism to implement the above user interface. Fred Hansen (412) 268-6788 wjh+@andrew.cmu.edu BITNET: wjh+@andrew for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh Omega say, "Enjoy the raspberries."