Re: How do various apps and DEs handle the primary selection?

On Monday 08 of July 2019, Jan-Marek Glogowski wrote:
> Hi
>
> I'm trying to gather information how various apps handle the primary
> selection, so I can fix tdf#104717 [1]. There is already a patch for that
> in Gerrit[2].
...
> IMHO we shouldn't handle the primary selection lifetime different from the
> clipboard lifetime. When selecting stuff, the primary should stay alive,
> even if I close the document or module, just like the normal clipboard. I
> don't see a point of clearing the selection at all, except on application
> shutdown, when the application won't be able to serve it anymore.
>
> How do other applications you know handle the primary selection?

 Variously. I don't think there's an official document on how the X11 
selections should work from the UI point of view. At least I'm not aware of 
that, and I'm saying that as somebody who used to practically maintain KDE's 
Klipper for about a decade and a number of times sent patches for Qt's 
QClipboard class.

 I think the idea is sort of that the PRIMARY selection is _the_ selection in 
the desktop. Just one in the entire desktop, which means that if you open two 
documents and  select text in both of them, there should be still just one 
visual representation, the one that is the X11 selection (i.e. making another 
selection removes the previous one, including the UI representation, you can 
see this e.g. if you try it with 2 xterm's). That's however rather silly and 
confusing from the usability point of view, as if the X11 clipboard handling 
wasn't confusing enough as it is, so often apps do not reset the previous UI 
representation or do other things slightly differently (and let's not forget 
that there are many apps that are buggy). So from this strict point of view, 
LO does everything properly. But from the practical point of view, I think 
that's a bad way of doing it. IMO people generally don't want their text 
editor UI selection to disappear just because they selected some text in some 
other app or dialog.

 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

 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.

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.

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).

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.

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.

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

-- 
 Luboš Luňák
 l.lunak@collabora.com