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

[Thomas Hudson <thudson tomy net>]

Havoc Pennington wrote:
>
> 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.

Actually I thought that was good practice. This differentiates between
what will be pasted with the middle button, as opposed to what will happen
when this app has focus and c-X/C/V is pressed. The dimmed selection should
be copied to the clipboard. Applications should mantain a clipboard selection
even when they lose primary selection, see reasons below.

> 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.
> 
I don't think this is always true. Our application has multiple frames,
each maintains it's own selection, each frame has it's own menu. The active
frame receives the cut/copy/paste keystrokes or menu actions. This is
important in two situations:

- Replacing selected text in one word processing document with selected 
text in another.
- Maintaining selection when selection was difficult for the user, ie.
a composed selection in a graphics document.

The rules we've used:
- When a user first selects something, this becomes the primary selection.
- When something else grabs primary, we dim it.
- For each frame with a dimmed selection, it grabs the clipboard selection
when it is active.

Tomy