Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!ATHENA.MIT.EDU!wdc From: wdc@ATHENA.MIT.EDU (Bill Cattey) Newsgroups: comp.windows.x Subject: Re: R3 Selection Mechanism Message-ID: Date: 25 May 89 20:02:52 GMT References: Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 107 I was hoping that someone else would respond to the issues raised by dsill, but already Fred is following them to a set of conclusions I don't like. > Excerpts from ext.in.xpert: 25-May-89 Re: R3 Selection Mechanism > dsill@relay.nswc.navy.mi (1611) > There is no one-size-fits-all selection interface. Beside the fact that > different interfaces suit different applications, the user is best > suited by providing customizable interfaces. > A typical counterexample to the single-selection-interface approach is > emacs. It has its own ideas of what constitutes a selection and how > selections are manipulated, and it's nothing like the interface Hansen > described. Is it right, then, to say to people new to X but with years > of emacs experience that they must use the new, "better" interface? > Would it be better to allow the user to decide which interface he > prefers and let him switch to the One True Selection Interface if and > when he's ready? Why not allow both to exist concurrently if they don't > get in each other's way? This person may not have been around when the mouse bindings for the selection interfaces for gnuemacs and xterm were being chosen. After gnuemacs adopted the ones from the X10 xterm, X11 xterm changed them. I spent several weeks hypnotizing myself to use the new bindings and to appropriately do without thinking the appropriate sequence depending upon whether I was in gnuemacs or xterm. Customizable interfaces are indeed good. Why, you may wonder have I not established my own mouse and key bindings and set them up if I hate the changing defaults so much? Two reasons: 1. I often help new users. I use the system defaults so that I reflexively do what they are supposed to do, and always know what the default is. If they have customized, I can ask them. If they have not, I must know the defaults because they may not. 2. The default bindings of the various common X applications such as X term, and their various customization mechanisms have changed so much that it is faster for me to learn the new defaults cold (much as I may hate them for their difference from what I am used to) than to learn the customization mechanism. I adopted a similar strategy back when the keyboard commands of the various versions of unix diverged. I taught myself to always say 'page' rather than 'p' or 'p1' or 'more' because that was the common pagination program common to all versions I was using at the time. ---- The most important issue here is being ignored: The ATK developers are willing to change their user interface if they hear suggestions that will make it more uniform with what other people use. I hate replies that say the selection mechanism can't be made to do the exact user interface stated, or that there is no best user interface, or that the only good interface is one that can be changed. I consider them lazy. Even silence would provide a space where a creative person could suggest something. Here is one suggestion which I have made privately to Andrew developers which I pose as a starting point for further discussion: 1. Instead of having 8 cut buffers common to all ATK windows, consider having each ATK application have its own seperate kill ring analagous to the gnuemacs kill ring. (I further suggest that the depth of the kill ring be a configurable parameter.) 2. That the X selection mechanism be used as a way to communicate among ATK and other X applications by providing mouse, menu, and key bindings that set the X selection appropriately when the cut/copy/paste/replace commands are issued to effectively share the topmost element of a particular window's kill ring. 3. Setting the selection: The current ez mouse bindings for highlighting text are the same as xterm's. Leave them that way. However it is inconvenient for ATK as it is written to make the highlit text into an X selection, so only make the highlit text an X selection when a cut/copy/paste/replace operation is performed. 4. Cut/Copy: When the cut or copy command is issued the highlit text is copied into the topmost element of the ATK window's kill ring. The window then asks for ownership of the selection if ever asked for the selection produces the topmost element of the kill ring, making such conversions as the ATK developers are interested in coding into their X support. 5. Paste: Tricky! We must prevent the selection from blowing away the topmost element of the window's kill ring. If there is a selection, not owned by this window, copy IT onto the kill ring, and insert the selection into the text. 6. Replace: First cut: ignore the X selections for simplicity. Remove the text from the buffer, rotate the window's kill ring, and insert the contents of the kill ring in its place. 7. Advanced replace: If there is a selection, not owned by the window, put it into the kill ring, rotate the kill ring, and ask for ownership of the selection. When a selection request comes in, produce an appropriately converted copy of the contents of the topmost element of the kill ring. Ok kids, I've got my asbestos eyeglasses all prepared for your replies. From the 'desk' of _ /| Bill (the) CATTey... \'o.O' ~(___)~ THSHVPPPOOO! U ACH!