Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


I CC'd some Calc devs. Maybe they know a bit more about this "select after
paste" behavior.

Am 08.07.19 um 12:29 schrieb Luboš Luňák:
On Monday 08 of July 2019, Jan-Marek Glogowski wrote:

[snip lot of background info - thanks for that]

 As for tdf#104717, my understanding of what happens is:
- after the first Ctrl+V, Calc pastes the new cell content
- as a part of that, it also selects the cell
- since the cell is selected, Calc also sets PRIMARY
- Klipper detects a change in PRIMARY, since it's set to synchronize it with 
CLIPBOARD, it sets CLIPBOARD to the contents of PRIMARY; Klipper does not 
support the advanced types Calc uses for representing cells, this only keeps 
it as plain text
- => next Ctrl+V pastes just the plain text

Yup. You're right.

 I see several ways of handling this:

1) Do not set PRIMARY for cell selections. I was originally going to say that 
pasting those cells with MMB doesn't work anyway, but to my surprise it 
actually does. Still, does somebody actually use that? And even if somebody 
does that inside LO, will they use it to MMB the cell contents into another 
app? I'm not aware of anything else using the mouse-select+MMB-paste 
mechanism for anything else than text. Based on this assumption I made 
#gerrit72369, and not setting PRIMARY at all would further remove 
interferences with tools like Klipper.

Gerrit 72369 is obsolete, as I rewrote the whole Qt5Clipboard to work async /
lazy, so no stuff is copied, just delivered / generated on request. And this way
we offer all the mime-types also on MMB paste.

Since the clipboard is "cheap" this way, I don't see a point to reduce the
available mime types to text/plain only.

2) Make Klipper handle all data types. Well, not really, I consider this 
unfeasible, but for completeness. It'd fix the content loss during 
synchronizing, but it'd lead to horrible performance problems of needless 
copying data all over the place.

Also my opinion. Most data is just generated on demand and doesn't exist until
someone requests it from the clipboard. Copying all mime types would become very
expensive for large selections, eventually.

3) Remove Klipper synchronization. I myself don't use it, but some people 
apparently do, although I can't say how popular it is. The point of the 
option is to remove the confusion of two different clipboards, making them 
appear as one. It makes sense to some people, my take is that most people 
don't even know mouse selecting should do something with clipboards, so for 
those it doesn't matter, and those that do this exit should also actually 
learn how to use it. So it can be shrugged off as NOTOURBUG (and I expect 
whoever maintains Klipper now will probably shrug it off too).

No idea, but the result is this bug report. Doesn't help if "both sides of the
bug" just claim NOTOURBUG :-)

4) Your patch. If I understand it correctly, it still keeps makes the new 
cells selected in the UI, it just avoids setting PRIMARY. I think that would 
kind of work, but it seems hackish.

Yuo're right. I have the impression that the "select after paste" is a known
feature of spreadsheet applications. gnumeric does the same. Now that is just a
sample size of two, but I can't do any better here. This is very uncommon, but
Eike mentioned in a comment of my patch that he couldn't MMB paste anymore,
after a normal paste, which is the whole point of the patch.

5) Don't select the pasted cells, not even in the UI. If I Ctrl+V in a text 
editor, the pasted text doesn't become selected either. This should 
(hopefully?) be simple, consistent and avoid the problem too.

As for 4). I have no way to evaluate, if people rely on the "select after paste"
feature, or if this is just some historical stuff, which can be dropped.

 I think the best one is 5), closely followed by 1).

IMHO 5) would definitely be the most consistent solution. 1) wouldn't help with
the problem. 4) seems to be the best compromise to avoid the bug and keep most
of the former behavior.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.