Re: [Owen Taylor <otaylor redhat com>] Re: copied item going away when you close the window you copied from

[Havoc Pennington <hp redhat com>]

Oskar Liljeblad <osk hem passagen se> writes: 
> Many applications do the other thing as well - when PRIMARY changes,
> they unselect the currently selected objects on screen (done by netscape,
> nedit, xterm). This is IMHO broken behavior. There is no reason (AFAIK)
> that two running applications should not be able to have different
> (visual) selections on screen.

The reason is that there's a concept of "the selection." If you don't
unselect when you lose the selection, then the user can't tell what
middle-mouse-paste or other operations on the selection will do.

For example, Mozilla is screwed up in this respect; it loses the
selection but still looks like it has it. So I have on several
occasions tried to paste its selection only to discover that it was
gone.

GtkEntry in GTK 1.2 has this concept of "selected in the app but not
the X primary selection," you'll notice that when it loses the
selection the selected text changes color (blue to gray) but remains
"selected." That is maybe a reasonable solution, though I never can
figure out how it works and I suspect most users would have no chance
of making any sense out of it. Anyway the feature got dumped in the
transition to Pango.

> Also, consider a Find-and-Replace dialog in a text editor. Such
> dialog usually has two text entries. The editor nedit has a
> feature called "Replace in selection" which allows you to
> perform the replacement operation on the selection in the
> main window only. Unfortunately, if you happen to select some text
> in the text entries in the dialog, you loose the main window
> selection. All you have to do it all over...

It's definitely wrong to allow multiple selections in one app - what
does the "copy" menu item copy? Far too confusing. Plus, how do you
unselect if not "by selecting something else or clicking elsewhere"?
You'd end up with all kinds of weird "selection dirt" hanging around.

> In some applications (especially xterm), it is impossible to
> insert the contents of CLIPBOARD. (It would make MORE sense if
> MiddleMouse inserted PRIMARY and Shift+Insert CLIPBOARD.)

Middle mouse does insert PRIMARY. If an app doesn't have a way to
paste CLIPBOARD, then that app is broken. But I'm guessing xterm has
some way, you just have to find it.

> <my opinion>
> An application should utilize either CLIPBOARD or PRIMARY,
> not both. One reason they choose CTRL+X/C/V for cut/copy/paste
> clipboard contents in many modern application is probably that
> you can use the mouse with one hand while pressing CTRL+X/C/V
> with the other. With select with mouse+insert with MMB you
> risk losing the selection by selecting something else by
> mistake (I often do this!). 

So just use the clipboard. The virtue of PRIMARY is that you can
totally ignore it.

> The middle mouse button could
> be used for more important tasks than paste PRIMARY
> (such as paste CLIPBOARD :)...

That's another issue, just a matter of mouse/key bindings. Many apps
let you customize it.

Havoc