How do various apps and DEs handle the primary selection?

[Jan-Marek Glogowski]

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.