I have the following issue: When copying from a GTK application running in wayland and pasting into a GTK application running in xwayland, suddenly all line endings are of the type \r\n instead of the original \n. As a real-life example one can copy from gedit running in wayland to gvim (via the register unnamedplus) running in xwayland.
I have done a bit of research and have found the following:
When copying text from a GTK TextView to the clipboard, there are multiple targets available, among them UTF8_STRING and text/plain;charset=utf-8. Both contain the string stored as UTF-8 but there is a slight difference: UTF8_STRING stores linebreaks as \n whereas text/plain;charset=utf-8 stores linebreaks as \r\n. This normalization to CRLF happens in https://gitlab.gnome.org/GNOME/gtk/blob/b64a4031006e29a9e54bccf85ff4a82251507307/gtk/gtkselection.c#L555. When pasting from text/plain;charset=utf-8, the result is normalized back to \n again: https://gitlab.gnome.org/GNOME/gtk/blob/b64a4031006e29a9e54bccf85ff4a82251507307/gtk/gtkselection.c#L629. The problem is that wlroots seems to sync text/plain;charset=utf-8 on the wayland side to UTF8_STRING on the xwayland side, so when pasting on the xwayland side the renormalization to \n does not happen.
Is there a reason why text/plain;charset=utf-8 is synced to UTF8_STRING instead of simply text/plain;charset=utf-8 again?
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
Is there a reason why text/plain;charset=utf-8 is synced to UTF8_STRING instead of simply text/plain;charset=utf-8 again?
We do want to have this as a fallback, but it would be a good idea to convert to UTF8_STRING only if the source doesn't expose text/plain;charset=utf-8.
We do want to have this as a fallback, but it would be a good idea to convert to UTF8_STRING only if the source doesn't expose text/plain;charset=utf-8.
Sorry, I do not understand. How could you convert from text/plain;charset=utf-8 to UTF8_STRING if the source does not expose text/plain;charset=utf-8? Do you instead mean "if the source does not expose UTF8_STRING"?
Ah, now I see. I would love to give this a try but I had a look at the code and think that I do not know enough C to get anywhere. So I'm going to turn this into a feature request.
Btw: thanks a lot for your and the other contributor's work on wlroots/sway! I will never look back to a non-tiling window manager :D
zickgraf
changed the title
Issue with clipboard target "text/plain;charset=utf-8" in wayland syncing to "UTF8_STRING" in xwayland
[Feature Request] Clipboard: set "text/plain;charset=utf-8" on the xwayland side if exposed by the source
Oct 13, 2019
Original Issue:
I have the following issue: When copying from a GTK application running in wayland and pasting into a GTK application running in xwayland, suddenly all line endings are of the type
\r\n
instead of the original\n
. As a real-life example one can copy from gedit running in wayland to gvim (via the register unnamedplus) running in xwayland.I have done a bit of research and have found the following:
When copying text from a GTK TextView to the clipboard, there are multiple targets available, among them
UTF8_STRING
andtext/plain;charset=utf-8
. Both contain the string stored as UTF-8 but there is a slight difference:UTF8_STRING
stores linebreaks as\n
whereastext/plain;charset=utf-8
stores linebreaks as\r\n
. This normalization to CRLF happens in https://gitlab.gnome.org/GNOME/gtk/blob/b64a4031006e29a9e54bccf85ff4a82251507307/gtk/gtkselection.c#L555. When pasting fromtext/plain;charset=utf-8
, the result is normalized back to\n
again: https://gitlab.gnome.org/GNOME/gtk/blob/b64a4031006e29a9e54bccf85ff4a82251507307/gtk/gtkselection.c#L629. The problem is that wlroots seems to synctext/plain;charset=utf-8
on the wayland side toUTF8_STRING
on the xwayland side, so when pasting on the xwayland side the renormalization to\n
does not happen.Is there a reason why
text/plain;charset=utf-8
is synced toUTF8_STRING
instead of simplytext/plain;charset=utf-8
again?wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1839
The text was updated successfully, but these errors were encountered: