home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / openloo / 4605 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  3.3 KB
  1. Path: sparky!uunet!news.gtech.com!noc.near.net!news.centerline.com!matt
  2. From: matt@centerline.com (Matt Landau)
  3. Newsgroups: comp.windows.open-look
  4. Subject: Re: Cut/Paste in OWN and more
  5. Date: 20 Nov 1992 17:56:53 GMT
  6. Organization: CenterLine Software, Inc.
  7. Lines: 61
  8. Message-ID: <1ej8t5INN1g0@armory.centerline.com>
  9. References: <84050@ut-emx.uucp>
  10. NNTP-Posting-Host: 140.239.1.32
  11.  
  12. In <84050@ut-emx.uucp> ich@ccwf.cc.utexas.edu (Ing-Chin Hwang) writes:
  13. >1. One of the most frequent window operations is select/copy in one
  14. >xterm and paste to another window, be it another xterm or a DECterm
  15. >from a remote VAX. 
  16. >
  17. >The X convention seems to be but1/drag is selection and but2 is
  18. >paste. 
  19.  
  20. Actually, there is no such thing as "the X convention" for copy and paste 
  21. operations.  There are at least three or four different conventions for 
  22. dealing with text operations, depending on the GUI style and toolkit you
  23. are using:
  24.  
  25.   * The Athena widgets convention, which is also used by xterm, is
  26.     that left-drag selects a region and places it into the PRIMARY
  27.     selection, while middle click copies in the contents of the
  28.     PRIMARY selection (or CUT_BUFFER0, if the PRIMARY selection is
  29.     empty) in at the current text insertion point.
  30.  
  31.   * Motif has a similar convention for using the PRIAMRY selection, 
  32.     except that middle click copies text in at the character position 
  33.     under the mouse pointer, even if the text insertion point is 
  34.     somewhere else.  (Personally, I find this behavior *incredibly* 
  35.     annoying.)  
  36.     
  37.     Motif also added one or two other conventions for copy and paste 
  38.     that use more persistent values, stored in the CLIPBOARD selection
  39.     instead of the PRIMARY selection.
  40.  
  41.   * OPEN LOOK does not use the PRIAMRY-based left/middle convention
  42.     at all, but uses an exclusively CLIPBOARD-based selection method
  43.     where positive action is required to copy the selected text to 
  44.     the CLIPBOARD selection (ususally this means pressing the Copy 
  45.     key), and selections are persistent until explicitly replaced by
  46.     a subsequent Copy operation.
  47.  
  48.   * Both OPEN LOOK and Motif (at least, as of Motif 1.2) also have
  49.     direct-manipulation drag-and-drop interfaces for text editing.
  50.  
  51. Completely interoperability requires that an application understand, or
  52. be able to understand, ALL of these conventions.  It's not conceptually
  53. hard except for drag-and-drop (where the OPEN LOOK protocol is utterly
  54. Byzantine and the Motif protocol is undocumented, which is even worse
  55. than being Byzantine!), but it seems like very few application or GUI
  56. toolkit developers go to the trouble of getting all the corner cases 
  57. right.
  58.  
  59. >Often times before the paste, I need to click on the menu/title
  60. >bar of the another window to bring it up front. This will then
  61. >de-select the region I just select. 
  62. >What's the best way to solve this problem? 
  63.  
  64. Well, you could use a focus-follows-pointer focus model in your window
  65. manager, so that you wouldn't have to direct input to it explcitly, or
  66. you could abandon the use of the left/middle mouse style of copy and 
  67. paste and switch to using one of the persistent CLIPBOARD-based methods
  68. instead.  You claim later that you don't want to do this, but it might
  69. be your best option.
  70. --
  71.  Matt Landau            Waiting for a flash of enlightenment
  72.  matt@centerline.com              in all this blood and thunder
  73.