Clipboard data lost after app is being closed (gtk2)

[AlexTP]

User wrote me about gtk2 version.
===
Details:

1. I cut some text in the clipboard from cudatext to another software,
2. before I paste, I close cudatext, and open the other software,
3. Then, I paste from clipboard, but nothing is there.
4. When I return to cudatext, the data than I have cut out is lost. Then I can find my data nowhere.
===
I found that my app had 'fix' for that issue here,
https://github.com/Alexey-T/CudaText/blob/master/comp/fix_gtk_clipboard.pas
 but this unit don't help today. I 'use' this unit in main form.
Any idea how to 'fix' that?

[dbannon]

I do, in the main form, the last one to close, this -

Code: Pascal  [Select][+][-]

1. procedure TMainForm.FormClose(Sender: TObject; var CloseAction: TCloseAction);
2. var
3.   {$ifdef LCLGTK2}
4.   c: PGtkClipboard;
5.   t: string;
6.   {$endif}
7.   .....
8. begin
9.     {$ifdef LCLGTK2}
10.     c := gtk_clipboard_get(GDK_SELECTION_CLIPBOARD);
11.     t := Clipboard.AsText;
12.     gtk_clipboard_set_text(c, PChar(t), Length(t));
13.     gtk_clipboard_store(c);
14.     {$endif}
15.      .....
16.  end;          

Its simplified of course, real thing is line #327 https://github.com/tomboy-notes/tomboy-ng/blob/master/source/mainunit.pas

Davo

[Fred vS]

Hello.

Akaik, with X11 (GTK uses X11), the only way to keep clipboard after close is via a clipboard manager.

I dont know GTK but for fpGUI who keeps the clipboard after close, the atom CLIPBOARD_MANAGER is used:

Code: Pascal  [Select][+][-]

1. atom_clipboard := XInternAtom(adisplay, pchar('CLIPBOARD_MANAGER'), False);

If atom_clipboard <> none then there is a clipboard manager installed.
In that case paste the clipboard of the application into the clipboard manager (2 lines of code).

So, lot of chance that GTK uses the same trick and if it does not work with Davo's code, it is maybe because the user does not have any clipboard manager installed.

Maybe.

Fre;D

[dbannon]

Not sure I agree Fred. While I have a clipboard manager installed on my working system, CopyQ, the model I have shown above also works fine on a "bare bones" U20.04 (where I build my releases).

I'm about to start pre release testing and that involves testing on several other platforms, so I'll watch for any issues on each and report back if I am disappointed. But I suspect everything needed is there in a standard install of GTK2.

Davo

[Fred vS]

Hi Davo.

It is totally possible that GTK uses a other trick but I am sure that in a fpGUI application, if you copy a text from it and close the application, the clipboard is not empty and you can paste it.

And for that fpGUI uses the atom CLIPBOARD_MANAGER.

Fre;D

[Nicole]

Yes, windows does this. This may be fine in most cases.
Because the programmer has not cleaned up his mess behind.

There are ways to make windows keeping it.
The clipboard is very complex and it is a security risk and therefore a matter of ongoing fixes by Microsoft.

You want to have a quick solution and this for all platforms?

I do it in the old way
HiddenMemo.Lines.SaveToFile(myClipboard.txt);

Later may be
HiddenMemo.Lines.LoadFromFile(myClipboard.txt); 

[dbannon]

Well, I have worked through 5 distros so far testing my own app. U2004 Mate, U2004 Gnome, OpenSUSE 15.4 Gnome, Debian Bullseye Mate and Debian Testing and the model I mentioned above has worked in all cases. Four of those were "out of the box" installs, more to come.

Davo

[Fred vS]

Well, I have worked through 5 distros so far testing my own app. U2004 Mate, U2004 Gnome, OpenSUSE 15.4 Gnome, Debian Bullseye Mate and Debian Testing and the model I mentioned above has worked in all cases.

Yes maybe because all those distros have a build-in clipboard manager.