I have a GTK4 GtkTextView with a GtkTextBuffer. When I copy a text block from gedit or the terminal window into the GtkTextView instance, and then call gtk_text_buffer_get_text() to extract the text, then line endings seems to be 0D0A on Linux. My feeling is, that the 0D is not from the initial text block, but inserted during the copy process. Was a bit surprising for me, is that behaviour intended? Or is my observation wrong?
To debug anything clipboard related, we need to know a bit more about your setup. Is this a regular GNOME Shell desktop? If so, what version? The clipboard path on Xorg and Wayland are quite different, which are you using here? Also, what version of GTK 4? Do you have a clipboard manager installed?
Terminal here gives me \n in the paste buffer from GTK 3-based gnome-terminal to GTK 4-based GtkTextView. Same goes for gedit.
Thanks for your fast reply.
I am using Gentoo-Linux AMD64 with
gnome-base/gnome-light-40.0:2.0::gentoo USE="gnome-shell -cups"
gui-libs/gtk-4.8.3:4::gentoo USE="X examples introspection wayland (-aqua) -broadway -colord -cups (-ffmpeg) -gstreamer -sysprof -test (-vulkan)" CPU_FLAGS_X86="f16c"
Should be a regular GNOME Shell desktop, running Wayland, no separate clipboard manager.
So when you think the generated 0D0A (CRLF) line endings may not be intended, then I may create a tiny test program in C. Actually, this behaviour is not a real problem for me, its easy to filter the text block, but it took me an hours to find this. I did first tests with directly typed in text, which worked fine, then months lather tried copied in text blocks, and noticed this strange behaviour. It is not that obvious, as the 0D0A are invisible.
gnome-shell --version would be a lot more helpful, but assuming gnome-light-40.0 means GNOME 40, then I’d suggest updating that first. Wayland clipboard and input APIs have gone through a lot of changes since then.
Sorry. Actually I wonder myself why they call it Gnome 40, see
But Gentoo-Linux is generally mostly up to date, close behind Arch-Linux. So execututing the command
gnome-shell --version
GNOME Shell 43.2
seems to indicate that I really have to provide a tiny example in C. Will try soon.
OK, I managed to create a C example. First my test data created with echo, and verified with hexdump:
salewski@hx90 /tmp/hhh $ echo -e "aa\nbb\ncc\n" > mytestdata
salewski@hx90 /tmp/hhh $ cat mytestdata
aa
bb
cc
salewski@hx90 /tmp/hhh $ hexdump -C mytestdata
00000000 61 61 0a 62 62 0a 63 63 0a 0a |aa.bb.cc..|
0000000a
As we can see, line end in only 0a, there is no 0d involved. Now I select the text block consisting of tree lines aa, bb, cc with mouse and use RMB copy to copy to clipboard. Then I launch the program from below, select the textview, and use RMB paste to insert the text block, which looks fine. Clicking the GTK button widget, does the hexdump showing the 0ds.
aa
bb
cc
61610d0a62620d0a63630d0a
When I launch the test program and type in the text block with keyboard directly, I get
$ ./t
aa
bb
cc
61610a62620a63630a
as desired. Below is the test program:
// based on www.gtk.org C example
// gcc -Wall t.c -o t `pkg-config --cflags --libs gtk4`
#include <gtk/gtk.h>
static void
print_hello (GtkWidget *widget, gpointer data)
{
GtkTextIter startiter, enditer;
GtkTextView *textView = GTK_TEXT_VIEW(data);
GtkTextBuffer *buffer = gtk_text_view_get_buffer(textView);
gtk_text_buffer_get_start_iter(buffer, &startiter);
gtk_text_buffer_get_end_iter(buffer, &enditer);
char *text;
text = gtk_text_buffer_get_text(buffer, &startiter, &enditer, 0);
g_print(text);
g_print ("\n");
//char s[] = "Hello";
char* cp = text;
for ( ; *cp != '\0'; ++cp )
{
g_print("%02x", *cp);
}
}
static void on_activate (GtkApplication *app) {
GtkWidget *window = gtk_application_window_new (app);
GtkWidget *box = gtk_box_new (GTK_ORIENTATION_VERTICAL, 0);
GtkWidget *button = gtk_button_new_with_label ("Hello, World!");
GtkWidget *textView = gtk_text_view_new();
gtk_box_append (GTK_BOX (box), button);
gtk_box_append (GTK_BOX (box), textView);
//g_signal_connect_swapped (button, "clicked", G_CALLBACK (gtk_window_close), window);
gtk_window_set_child (GTK_WINDOW (window), box);
g_signal_connect (button, "clicked", G_CALLBACK (print_hello), textView);
gtk_window_present (GTK_WINDOW (window));
}
int main (int argc, char *argv[]) {
// Create a new application
GtkApplication *app = gtk_application_new ("com.example.GtkApplication",
G_APPLICATION_DEFAULT_FLAGS);
g_signal_connect (app, "activate", G_CALLBACK (on_activate), NULL);
return g_application_run (G_APPLICATION (app), argc, argv);
}
You can try running with WAYLAND_DEBUG=1 to see what is going on with the clipboard protocol.
Before this thread will get closed automatically (I guess after 4 weeks still?):
Yes I tried WAYLAND_DEBUG=1 and got a lot of output. But I had no real idea what to do with it. Do you think this is an issue, or may it be actually intended behaviour? And if it is an issue, should I post it to some issue tracker like Github or Gitlab, or do we have already enough more important issues there? At least this one was more important for me PangoCairo underline markup issue (#5336) · Issues · GNOME / gtk · GitLab, and there seems to be some progress recently 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.