Clipboard not fully working

[sfein1000]

Setup:
Linux - Debian Pixie with KDE desktop and Wayland
FPC: 3.2.2 installed using fpcupdeluxe
FPGui: 2.1.0 - compiled with unix

I am trying to use the clipboard using code like:
fpgClipboard.Text := ddlbPath.Items[ddlbPath.FocusItem]

which copies the currently selected item from the comboox to the clipboard.

When I do this, I checked KDE's clipboard history, does not show up. I open kwrite and paste, nothing happens. I added an fpg_edit to the app. Ran the copy and then CTRL-V into the edit and that worked. But kde apps still do not see it. I ran maximus as another test. I was able to copy and paste within the ide, but again kde apps did not see it. I also tried copying from my app and pasting into maximus and that did not work.

It seems like the clipboard is just for the one app and nothing outside of the app. Is this a wayland or kde thing? Is there more to using the clipboard?

Thanks
Steve

[fredvs]

Hello.
I'm afraid this is a Wayland issue. For security reasons, Wayland doesn't allow clipboard access outside of the application itself.
Have you tried using the X11 graphics server?

[sfein1000]

If wayland blocks clipboard access outside of app, why does clipboard work for all other apps (copy from web browser to kwrite or even vim). Or is this an XWayland limitation?

I used to use X11, but I prefer to use the default for my distribution and Debian seems set on using Wayland.

[fredvs]

Hmm, I don't know (I'm not a fan of Wayland, I prefer XLibre), but it seems to me that to answer the question, you could test using an X11 session. Does Debian Pixie allow login by choosing X11 instead of Wayland?

[andrewd207]

@fredvs that doesn't make sense. Most of the functionality of the clipboard is to move text/images between apps. The only restriction I'm aware of is setting the clipboard contents when your app is not focused. And that's a native wayland client restriction that may not apply to XWayland.

[andrewd207]

The x11 clipboard (on xwayland) is working for me

[andrewd207]

Having said that the problem is likely

fpGUI/framework/src/main/pascal/corelib/x11/fpg_x11.pas

Line 4276 in b55b67d

//targets[3] := XInternAtom(xapplication.Display, 'UTF8_STRING', True);

UTF8_STRING is commented out for some reason

[fredvs]

@sfein1000 : Maybe you can try the fpGUI Wayland target done by Andrew, it works great: #193

#193 (reply in thread)

[andrewd207]

@sfein1000 If you copy this to your clipboard and from the fpgui source folder do
wl-paste | patch -p1 and recompile.
If you don't have wl-paste you can just save it to a file and do
patch -p1 < the.patchfile.patch

diff --git a/framework/src/main/pascal/corelib/x11/fpg_x11.pas b/framework/src/main/pascal/corelib/x11/fpg_x11.pas
index ce77e9b5..84a746a8 100644
--- a/framework/src/main/pascal/corelib/x11/fpg_x11.pas
+++ b/framework/src/main/pascal/corelib/x11/fpg_x11.pas
@@ -352,6 +352,11 @@   TfpgX11Application = class(TfpgApplicationBase)
     xia_net_wm_icon: TAtom;
     xia_targets: TAtom;
     xia_save_targets: TAtom;
+    { text flavours we advertise for the selection/clipboard }
+    xia_utf8_string: TAtom;
+    xia_text_plain_utf8: TAtom;
+    xia_text_plain: TAtom;
+    xia_text: TAtom;
     netlayer: TNETWindowLayer;
     InputMethod: PXIM;
     InputContext: PXIC;
@@ -815,7 +820,9 @@ procedure ProcessSelection(var ev: TXEvent);
 end;
 
 // clipboard event
-procedure HandleAtom(var e: TXSelectionEvent; const Atom: TAtom; Prop: TAtom); forward;
+{ Returns False when we cannot supply the requested target, so the caller can
+  refuse the conversion properly (ICCCM: reply with property = None). }
+function HandleAtom(var e: TXSelectionEvent; const Atom: TAtom; Prop: TAtom): Boolean; forward;
 
 
 procedure HandleMultiple(var e: TXSelectionEvent);
@@ -863,10 +870,23 @@   TAtomPair = record
   end;
 end;
 
-procedure HandleAtom(var e: TXSelectionEvent; const Atom: TAtom; Prop: TAtom);
+{ True for the targets DoSetTargets advertises as plain text. We hand back the
+  stored UTF-8 bytes for each of them. }
+function IsTextTarget(const Atom: TAtom): Boolean;
+begin
+  Result := (Atom = XA_STRING)
+         or (Atom = xapplication.xia_utf8_string)
+         or (Atom = xapplication.xia_text_plain_utf8)
+         or (Atom = xapplication.xia_text_plain)
+         or (Atom = xapplication.xia_text);
+end;
+
+function HandleAtom(var e: TXSelectionEvent; const Atom: TAtom; Prop: TAtom): Boolean;
 var
   clip: TfpgX11Selection;
+  data: PByte;
 begin
+  Result := False;
   if Atom = None then
   begin
     Exit; // ==>
@@ -879,18 +899,28 @@ procedure HandleAtom(var e: TXSelectionEvent; const Atom: TAtom; Prop: TAtom);
   if Atom = xapplication.xia_targets then
   begin
     clip.DoSetTargets(e.requestor, Prop);
+    Result := True;
   end
   else if Atom = XInternAtom(xapplication.Display, 'MULTIPLE', False) then
   begin
     // multiple targets
     HandleMultiple(e);
+    Result := True;
   end
-  else// if Atom = XA_STRING then
+  else if IsTextTarget(Atom) then
   begin
+    if clip.FClipboardText = '' then
+      data := nil
+    else
+      data := PByte(@clip.FClipboardText[1]);
     XChangeProperty(xapplication.Display, e.requestor, Prop, Atom,
-              8, PropModeReplace, PByte(@clip.FClipboardText[1]), Length(clip.FClipboardText));
+              8, PropModeReplace, data, Length(clip.FClipboardText));
+    Result := True;
   end;
-  //else WriteLn('Unhandled Selection atom: ', XGetAtomName(xapplication.Display, Atom));
+  { Anything else (TIMESTAMP, image/*, application/*, ...) we cannot supply.
+    Returning the text bytes typed as the requested target - as this used to do
+    - hands the requestor garbage, and clipboard managers that probe with a
+    target they know we should not have will reject the whole offer. }
 end;
 
 procedure ProcessSelectionRequest(var ev: TXEvent);
@@ -905,7 +935,10 @@ procedure ProcessSelectionRequest(var ev: TXEvent);
   e.time        := ev.xselectionrequest.time;
   e._property   := ev.xselectionrequest._property;
 
-  HandleAtom(e, e.target, e._property);
+  { ICCCM: a conversion we cannot perform must be refused by sending back the
+    SelectionNotify with property = None, not by inventing data for it. }
+  if not HandleAtom(e, e.target, e._property) then
+    e._property := None;
 
   XSendEvent(xapplication.Display, e.requestor, false, 0, @e );
 end;
@@ -1756,6 +1789,10 @@ constructor TfpgX11Application.Create(const AParams: string);
   xia_selection         := XInternAtom(FDisplay, 'PRIMARY', TBool(False));
   xia_targets           := XInternAtom(FDisplay, 'TARGETS', TBool(False));
   xia_save_targets      := XInternAtom(FDisplay, 'SAVE_TARGETS', TBool(False));
+  xia_utf8_string       := XInternAtom(FDisplay, 'UTF8_STRING', TBool(False));
+  xia_text_plain_utf8   := XInternAtom(FDisplay, 'text/plain;charset=utf-8', TBool(False));
+  xia_text_plain        := XInternAtom(FDisplay, 'text/plain', TBool(False));
+  xia_text              := XInternAtom(FDisplay, 'TEXT', TBool(False));
   xia_motif_wm_hints    := XInternAtom(FDisplay, '_MOTIF_WM_HINTS', TBool(False));
   xia_wm_protocols      := XInternAtom(FDisplay, 'WM_PROTOCOLS', TBool(False));
   xia_wm_delete_window  := XInternAtom(FDisplay, 'WM_DELETE_WINDOW', TBool(False));
@@ -4265,16 +4302,22 @@ procedure TfpgX11Selection.DoLostSelection;
 
 procedure TfpgX11Selection.DoSetTargets(AWin: TWindow; AProperty: TAtom);
 const
-  target_count = 3;
+  target_count = 7;
 var
   targets: array[0..target_count-1] of TAtom;
 begin
-
-  targets[0] := XA_STRING;
-  targets[1] := xapplication.xia_targets;
-  targets[2] := xapplication.xia_save_targets;
-  //targets[3] := XInternAtom(xapplication.Display, 'UTF8_STRING', True);
-  //targets[4] := XInternAtom(xapplication.Display, 'MULTIPLE', True);
+  { fpGUI stores selection text as UTF-8, so the UTF-8 flavours must be listed
+    first: well behaved pasters (GTK, Qt, Chromium, XWayland's X->Wayland
+    clipboard bridge) ask for TARGETS and then request only what is listed
+    here. Advertising XA_STRING alone meant they either got nothing at all, or
+    fell back to STRING and decoded our UTF-8 bytes as Latin-1. }
+  targets[0] := xapplication.xia_utf8_string;
+  targets[1] := xapplication.xia_text_plain_utf8;
+  targets[2] := xapplication.xia_text_plain;
+  targets[3] := xapplication.xia_text;
+  targets[4] := XA_STRING;
+  targets[5] := xapplication.xia_targets;
+  targets[6] := xapplication.xia_save_targets;
 
   // list the types of data we have in the clipboard
   XChangeProperty(xapplication.Display, AWin, AProperty, XA_ATOM, 32,

[sfein1000]

Just so I am clear. The patch command should be run from main fpgui folder (where framework is listed as a folder - along with others). Also, is the patch correct? Last line looks like it is missing values and a closing paren. Or is that normal because it didn't change?

[sfein1000]

What the heck, just ran it anyway. Can always recover mistakes. :)

The patch worked. I can copy from my app now. Thank you.

[andrewd207]

I think the patch is correct. They usually just have 3 lines from the original at the end, per hunk. I'm installing debian in a vm at the moment to test this

[graemeg]

thank you Andrew - I'll review tonight and get it into the repo ASAP.

[graemeg]

Thanks Andrew — patch reviewed and applied, and thanks Steve for the report and for testing it.

Landed on develop in b5c7ac5.

The diagnosis was spot on

Three real fixes in there:

UTF8_STRING in TARGETS — the actual cause. DoSetTargets advertised only XA_STRING, so GTK/Qt/Chromium and XWayland's clipboard bridge either got nothing or decoded our UTF-8 bytes as Latin-1. That explains the exact shape of Steve's symptom: pasting worked within fpGUI, because both ends spoke the same bytes, but nothing outside could read it.

ICCCM refusal — making HandleAtom a function so ProcessSelectionRequest can reply property = None for targets we can't supply. Previously any target got the text bytes back mislabelled as that target, so a clipboard manager probing with TIMESTAMP or image/png received garbage. That's very likely why KDE's clipboard history stayed empty even when the paste itself worked.

Empty-string guard — @FClipboardText[1] on an empty string. Latent bug, good catch.

The else-chain ordering is right too: TARGETS and MULTIPLE are tested before IsTextTarget, so they can't be swallowed by the text branch.

One gap I filled in

The patch fixes copying out of fpGUI. Pasting in was still:

XConvertSelection(..., XA_STRING, ...)   // ICCCM: Latin-1

while ProcessSelection stores the returned bytes verbatim into FClipboardText, which is UTF-8. So the two sides disagreed — copy café or € from Firefox into fpGUI and you'd get mojibake. Same class of bug, opposite direction, invisible in an ASCII test and in fpGUI-to-fpGUI copying.

So DoGetText now asks for UTF8_STRING, with a one-shot fallback: if the owner refuses, ProcessSelection retries once with XA_STRING for older clients, guarded by a flag so it can't loop. The retry deliberately leaves FWaitingForSelection set so the wait loop parks for the second reply instead of returning empty.

Still worth testing

Steve confirmed the write side. The part that would benefit from another pair of hands is the read side — pasting non-ASCII text into an fpGUI app from a browser or KWrite (café € is a good test). If either of you gets a chance, that'd be appreciated.

Two pre-existing issues I left alone, both predating this patch and worth their own fix:

• ProcessSelection caps reads at 16000 bytes and ignores remaining, so large clipboard content is silently truncated — proper INCR support is a separate piece of work.
• Clipboard behaviour isn't covered by the test suite at all; it needs a live X session and a second app, so it stayed manual here.

Graeme

[rchastain2]

I copied (café € is a good test) from my web browser to nanoedit, and then from nanoedit to another text editor.

As you can see below, it works, but in the second case the string is truncated.

[graemeg]

Thank you for testing again. That wasn't actually a clipboard issue, but a TfpgTextEdit widget issue, mixing Copy() and UTF8Copy() - one is bytes and the other is characters. It worked perfectly with the TfpgMemo for example.

While in the TfpgTextEdit code, I discovered a few other bugs I fixed too. I also implemented the > 16KB clipboard support.

[graemeg]

I just implemented INCR support for X11 clipboard, and managed to copy and paste, out of Maximus and into Maximus 900KB of text to/from Kate. So large amounts of text are working well too.

[sfein1000]

I downloaded dev and compiled. Added a Edit control to app. In browser I copied a euro symbol (no idea how to type in unicode on my machine in fpgui) and pasted. Edit showed the euro. I then opened kwrite, entered an A with a slash thru it (unicode 570 decimal). Copied it and pasted in kwrite (just to verify clipboard had that symbol). Went back to my app and copied the euro from the edit control and pasted into kwrite and it pasted correctly.

So for my minor tests, it all seems to work.