[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Annoyances] X-Windows Copy & Paste
- From: Owen Taylor <otaylor redhat com>
- To: Thomas Leonard <tal00r ecs soton ac uk>
- Cc: xdg-list redhat com
- Subject: Re: [Annoyances] X-Windows Copy & Paste
- Date: Tue, 19 Aug 2003 10:20:50 -0400
On Tue, 2003-08-19 at 05:15, Thomas Leonard wrote:
> On Tue, Aug 19, 2003 at 01:55:45AM -0700, John Meacham wrote:
> [...]
> > It occurs to me that since xterm does not allow modification of the text
> > being selected, there is no point in not setting CLIPBOARD on selection.
> > since the point of setting CLIPBOARD independently of PRIMARY is to
> > allow replacement of the selected text with a paste from another app.
> > i.e. no functionality is lost, but we gain the ability to paste X
> > selections into apps with explicit paste commands.
>
> Changing the clipboard on selection destroys the purpose of the clipboard!
> The clipboard is a more persistant version of the selection (ie, I can
> select and change text without changing the clipboard). Changing the
> clipboard without the user's permission would be terrible UI (and also
> inconsistant if you only do it in read-only areas).
>
> Looks like gnome-terminal already has this bug (what does the Copy menu
> item do, then, if selecting already sets CLIPBOARD?). As far as I can see:
>
> - Select text sets PRIMARY and CLIPBOARD.
> - Copy does nothing.
> - Paste pastes CLIPBOARD.
> - Button-2 pastes PRIMARY.
Please retest. I've never seen vte do that, I'd be over at Nalin's
desk in a second if it did... and the source code looks fine.
What is probably confusing you is that Shift-Insert pastes primary
rather than clipboard for consistency with xterm (and because
people found it convenient). The default clipboard bindings for
gnome-terminal are Ctrl-Shift-C Ctrl-Shift-V.
> Reminding everyone to set PRIMARY when they set CLIPBOARD sounds fine,
> though. Windows users won't expect to be able to Paste until they Copy,
> and normally it won't matter which Paste they use, since both are set the
> same.
This isn't consistent with the clipboard explanation - the clipboard
explanation says that primary should *always* be the selected text
and nothing else.
There is some good argument that we should change the way that PRIMARY
is treated in the clipboard explanation - many toolkits don't implement
what's there now either. (GTK+ sticks to it exactly)
There was a long, inconclusive discussion between Lubos Lunak and
me about this last fall, spread between various lists. In
https://listman.redhat.com/archives/xdg-list/2002-November/msg00046.html
I said:
I think the simple model that corresponds best to what you
are proposing is
Middle-mouse-button implements a "short-cut paste" that pastes
the most recent of:
- text selected explicitely by the user with the mouse or keyboard
- text cut to the clipboard
[ Yes, this isn't done currently, but it's the only way
I see of putting 6) into any consistent framework ]
Then you would need to combine this model with some
PRIMARY-selection-independent model of how selections should
work in widgets.
6) was about making "copy link location" copy to PRIMARY as well
as CLIPBOARD.
Regards,
Owen
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]