You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 1, 2021. It is now read-only.
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: