On Linux Gtk2, over time I have noticed a problem where data copied to the clipboard by a Lazarus application does not persist on the clipboard after the Lazarus program has exited.

While writing this application
<https://cache.getlazarus.org/images/desktop/capture-tool.png> that captures image data to the clipboard, the data on the clipboard is only available to other applications while mine is running. If I exit my program the clipboard data goes away. The same problem occurs if the clipboard data is text rather than a bitmap.

Is this a known issue on Linux LCL Gtk2? Is there a workaround?

Thank you for your attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/326a81b7/attachment.html>

This is the way the linux clipboard works - the data is kept with the source program, so goes when the program closes.

Colin

I noticed a recent discussion touching on this problem posted by Bo Berglund on November 20, 2020 to this same mailing list.

Andreas Schneider replied in that thread, 'Pasting basically asks the application that "copied" it to get the content. If that app is gone in the meantime, there's nothing to paste anymore.'

Also, Colin Western replied this is how Linux applications work, 'the data is kept with the source program, so goes when the program closes'.

I disagree.

I've tested several Gtk2 applications, including older versions of Gimp and Geany. Both these programs have clipboard copy functions and the data on the clipboard from those applications my tests show their clipboard data persists after they have been closed. So it would seem that Gtk2 the clipboard works correctly and handles persisting data after an application has exited.

I stepped through the LCL source and it looks like the clipboard code is using some Gtk clipboard functions, and not using X windows functions, thereby introducing a possible problem, but I am unsure if the LCL is using the Gtk clipboard correctly. That is, the LCL might be using some Gtk clipboard functions which seem to work well, but exhibit the problematic behaviour I've described.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/f3ccfabc/attachment.html>

I am very confident that the X11 behaviour is that the data goes with the application. It might be that more recent desktops/toolkits have some work around, but the gtk2 functions lazarus uses only copy data externally when asked for by an X11 messaage and this is all gtk2 provides.

Colin

I think the programs you tested use some extra functions, because as these 2 persons already said: under X11, the selection is owned by the program, not by X11.

See e.g.

https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html https://wiki.ubuntu.com/ClipboardPersistence

for an explanation.

Basically: if you don't communicate with a persistent clipboard app, then
nothing will happen to persist your selection.

Michael.

Perhaps there is a Linux service that can be used by applications to hand over and take ownership of clipboard data, and applications such as those I mentioned are using it in order to solve the problem I am describing? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/1f468bf2/attachment.html>

Anthony Walter wrote

Perhaps there is a Linux service that can be used by applications to hand over and take ownership of clipboard data, and applications such as those I mentioned are using it in order to solve the problem I am describing?

See my earlier reply for some links.

Michael.

Thanks Michael.

It looks as if this problem was fixed in Gtk2 by version 2.6. The developers added this function to work around this problem:

void gtk_clipboard_store (GtkClipboard *clipboard);

Stores the current clipboard data somewhere so that it will stay around after the application has quit.

Parameters
clipboard

a GtkClipboard

Since: 2.6

Looking at the LCL source, it seems the Gtk3 LCL is using this function to save the clipboard data after the program exists, but it's not being used in the Gtk2 LCL. With this function, the problem I've described should be fixable in LCL Gtk2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/4e0593a3/attachment.html>

Here is a follow-up.

I wrote a simple test using LCL Gtk2 and gtk_clipboard_store. This test allows the clipboard data to persist after my program exited. Button1 click sets the clipboard data. If Button2 clicked the data will persist after the program exits. If Button2 is not clicked, the data does not persist. Curiously, as the LCL Gtk2 currently stands, gtk_clipboard_store() does not work. I suspect the LCL is not using the same GdkAtom clipboard as returned by gtk_clipboard_get(GDK_SELECTION_CLIPBOARD).

uses
  Gtk2, Gdk2;

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  S: string;
begin
  S := Edit1.Text;
  gtk_clipboard_set_text(gtk_clipboard_get(GDK_SELECTION_CLIPBOARD),
PChar(S), Length(S))
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
  gtk_clipboard_store(gtk_clipboard_get(GDK_SELECTION_CLIPBOARD));
end;
procedure TForm1.Button3Click(Sender: TObject);
begin
  Close;
end;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/f2ed69af/attachment.html>

(You have definitely educated me)

I tried something similar on one of my own applications, and it doesn't work for me either. I suspect sometihing more elaborate is required, as I don't think the LCL does calls gtk_clipboard_set_text, even for text. Reading the documentation for gtk_clipboard_set_can_store suggests this should be called also, but a quick trial of this didn't work either.

Colin

Colin,

After some research I've found that LCL Gtk2 isn't using gtk_clipboard_x functions, rather it's using gtk_selection_x functions. There are gtk_clipboard functions to do the same thing as gtk_selection functions, but because the gtk_clipboard functions are not being used, the gtk_clipboard_store function does not work with the LCL Gtk2 clipboard. I've written a mini clipboard class that allows for multiple formats on the clipboard at the same time and it works well and also allows clipboard data to persist after my application closes, but my design does not conform to the WS (widgetset) model used by the LCL, and thus operates outside of the LCL.

In the end, I'm confident that if LCL Gtk2 were written to use gtk_clipboard functions instead of gtk_selection functions, the problem could be fixed. I do not mean to place blame on any of the LCL Gtk2 developers, as the gtk_clipboard functions were most likely developed and released sometime after the first few iterations of Gtk2. Particularly, the gtk_clipboard_set_can_store did not exist until Gtk 2.6. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210401/29c86f6b/attachment.html>

Anthony Walter wrote

I noticed a recent discussion touching on this problem posted by Bo Berglund on November 20, 2020 to this same mailing list.

I'm back...
In fact I have a *related* clipboard issue inside Lazarus itself:

Working in Lazarus via a VNC connection to a RaspberryPi (Lazarus is on the RPi).

If I try to search for a string which I have copied in Windows the following happens:

- String copied in Windows
- Use Ctrl-V in Lazarus and the string is pasted into the code editor OK
- This shows that the string is in the clipboard

- String again copied in Windows
- Hit F3 in Lazarus to start a search, a bogus search term appears
- Use Ctrl-V to paste the copied string into the Lazarus search dialog
- Nothing happens...

- Go back to windows and re-copy the string
- In Lazarus select the bogus search item in the dialog
- Try to replace it with Ctrl-V
- Nothing happens...

- Finally go back to Windows and again copy the search string
- Now in Lazarus use Backspace to erase the bogus search item in the existing search dialog which was not closed
- Hit Ctrl-V to paste the search string
- NOW FINALLY! The string is pasted into the search dialog

It seems like the clipboard is cleared (or replaced) by the following opertations in Lazarus:
- Using F3 to start a search operation with nothing selected in the source
- Selecting the bogus word in the search dialog in order to replace it

Why this behaviour? I am constantly being hit with this when I am porting a Windows application from Delphi to Linux-FreePascal. I have the project open in Windows and the converted project in Linux and trying to navigate via searches is just so cumbersome with this behaviour.

Just s general warning, it doesn't say anything about your observations.

Be careful with drawing conclusions when using vnc. The past year I've been working remote and I'm using vnc to access my clipboard data most times work, but sometimes it is a pain. It won't copy or paste the right selection. Reconnecting vnc usually solves the issue. This is independent of the source or target application.

So the issue you observed might be caused by vnc or it might be indeed an issue in Lazarus

Marc

Just as a test with Lazarus on Windows I repeated the sequences I described when copying the same text as before on Windows (in Notepad++) and then using Ctrl-F or F3 inside Lazarus on Windows in order to start a new search. The search dialog was showing a nonrelated search string but Ctrl-V worked just fine to replace it with my copied text.

Here of course VNC is not involved and all operations happened in Windows.

So I now went into the VNC session on Linux and there I opened a text editor in addition to Lazarus.
I entered text into the text editor and then coped one word there.

Back into Lazarus (still in Linux) I used both Ctrl-F and F3 to start search dialogs and in both cases there was an unrelated search term coming up, but also in both cases using Ctrl-V to paste my previously copied text worked fine!

So I must concur with your observation that this case is a VNC clipboard issue! Good to know, but disturbing nevertheless...

Now I remember having read that Linux has more than one clipboard, possibly VNC is using the "wrong" one?

But it still works when just copying text from Windows and pasting it directly into the Lazarus code editor in Linux...

Just not into the search dialog.