From: matt@centerline.com (Matt Landau)
Newsgroups: comp.windows.open-look
Subject: Re: Cut/Paste in OWN and more
Date: 20 Nov 1992 17:56:53 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.1.32

In <84050@ut-emx.uucp> ich@ccwf.cc.utexas.edu (Ing-Chin Hwang) writes:
>1. One of the most frequent window operations is select/copy in one
>xterm and paste to another window, be it another xterm or a DECterm
>from a remote VAX. 
>
>The X convention seems to be but1/drag is selection and but2 is
>paste. 

Actually, there is no such thing as "the X convention" for copy and paste 
operations.  There are at least three or four different conventions for 
dealing with text operations, depending on the GUI style and toolkit you
are using:

  * The Athena widgets convention, which is also used by xterm, is
    that left-drag selects a region and places it into the PRIMARY
    selection, while middle click copies in the contents of the
    PRIMARY selection (or CUT_BUFFER0, if the PRIMARY selection is
    empty) in at the current text insertion point.

  * Motif has a similar convention for using the PRIAMRY selection, 
    except that middle click copies text in at the character position 
    under the mouse pointer, even if the text insertion point is 
    somewhere else.  (Personally, I find this behavior *incredibly* 
    annoying.)  
    
    Motif also added one or two other conventions for copy and paste 
    that use more persistent values, stored in the CLIPBOARD selection
    instead of the PRIMARY selection.

  * OPEN LOOK does not use the PRIAMRY-based left/middle convention
    at all, but uses an exclusively CLIPBOARD-based selection method
    where positive action is required to copy the selected text to 
    the CLIPBOARD selection (ususally this means pressing the Copy 
    key), and selections are persistent until explicitly replaced by
    a subsequent Copy operation.

  * Both OPEN LOOK and Motif (at least, as of Motif 1.2) also have
    direct-manipulation drag-and-drop interfaces for text editing.

Completely interoperability requires that an application understand, or
be able to understand, ALL of these conventions.  It's not conceptually
hard except for drag-and-drop (where the OPEN LOOK protocol is utterly
Byzantine and the Motif protocol is undocumented, which is even worse
than being Byzantine!), but it seems like very few application or GUI
toolkit developers go to the trouble of getting all the corner cases 
right.

>Often times before the paste, I need to click on the menu/title
>bar of the another window to bring it up front. This will then
>de-select the region I just select. 
>What's the best way to solve this problem? 

Well, you could use a focus-follows-pointer focus model in your window
manager, so that you wouldn't have to direct input to it explcitly, or
you could abandon the use of the left/middle mouse style of copy and 
paste and switch to using one of the persistent CLIPBOARD-based methods
instead.  You claim later that you don't want to do this, but it might
be your best option.
--
 Matt Landau			Waiting for a flash of enlightenment
 matt@centerline.com			  in all this blood and thunder
Newsgroups: comp.windows.open-look