Georg Baum wrote:
I think that I now fully understand how the selection is handled in LyX.
/me too ;-)
I
have now documented the current code, and fixed some bugs, see the cvslog
postings or read the code for details. Since there have been several
opinions how selection should work I'll outline here the possible options.
Let's start with our internal clipboard stack: This is advertised to the
user in the "paste recent" menu. If you know this it suddenly makes sense
that a middle mouse button press pushes the current selection to the
internal clipboard. So this is not a hack, but done on purpose. This is
only done for middle mouse button paste and not for C-v, since in the
latter case the stuff is already in the clipboard (at least if it comes
from within LyX). Unfortunately this is only done in text, not in math nor
in tables. The attached patch x.diff implements the same mechanism for
tables and math and should go in IMO. Any objections?
Fine with me.
The next question: The clipboard stack is not really a "paste recent"
stack: If you copy something in LyX without pasting it is nevertheless
added, and anything that is pasted but comes from outside (selection or
clipboard) is not added. That means that it is a bit inconsistent. To make
it consistent, we could decouple the stack from the clipboard and always
fill it on paste. The only disadvantage I see in doing so is that items
that you only copy do not appear anymore in the stack. Opinions?
IMHO, what is important is what you paste not what you copy. So I think
"paste recent" should only present what have been pasted recently
regardless of what has been copied. I often change my mind when I hit
C-c and I don't want all those tentative to show up in the menu.
So I'd say decouple.
[...]
Question: Do we want to advertise keyboard and mouse selections differently
to X? IMO we should not, and because we do our own selection handling and
don't use qApp->clipboard()->setText() for this there is no performance
penalty. Unless there are some very good reasons not to advertise
selection changes by keyboard to X I am going to add the missing
haveSelection calls.
I've changed my mind on this point after reading the freedesktop
document so I'd say go for it.
Fake X selection for windows and Mac: The patch I originally sent is not
needed anymore if the patch x.diff in this message is applied, since then
the internal selection is always used if available. If we want to paste
the clipboard with the middle mouse button on systems that don't have a
selection then we should do it like the patch fake-selection.diff. This is
against the "simple mental model" of the selection, so I don't like it,
but if windows users agree that this is useful I won't object.
I personally like it and I am sure others will (and Enrico will be the
first ;-)). But I could live without and just using mouse-click plus Ctrl-v.
Persistent selection: Some people want that a selection is still available
for middle mouse button paste after it is not visible on screen anymore,
and several applications implement that. This is against the "simple
mental model": The equation "selection == highlighted text on screen"
would not be true anymore. It is not needed either: It makes sense for
applications that don't have a clipboard, but since we have one we can as
well use C-c and C-v for copy/paste.
If a majority does not agree with me and somebody volunteers to implement
persistent selections I can outline how it can be done, but I won't
implement it myself. This is not very difficult to do, but would require
some code reorganizations.
I don't care for persistent selection and I agree that the Clipboard is
here for that.
Related to persistent selections: Should a recieved SelectionClear event
clear the LyX selection or not? Again, some apps do this and others don't.
http://www.jwz.org/doc/x-cut-and-paste.html recommends to honor this
request, and this is currently done in LyX.
Internally, when using multiple views, I am strongly against
un-selecting a selected text when this selected text is pasted onto the
other view. Externally (when a SelectionClear event is received) I could
live with a deselection but that would be inconsistent with the internal
behaviour. So I'd prefer that we don't.
Abdel.
