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.
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"?
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\ninstead 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
text/plain;charset=utf-8. Both contain the string stored as UTF-8 but there is a slight difference:
UTF8_STRINGstores linebreaks as
text/plain;charset=utf-8stores 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
\nagain: https://gitlab.gnome.org/GNOME/gtk/blob/b64a4031006e29a9e54bccf85ff4a82251507307/gtk/gtkselection.c#L629. The problem is that wlroots seems to sync
text/plain;charset=utf-8on the wayland side to
UTF8_STRINGon the xwayland side, so when pasting on the xwayland side the renormalization to
\ndoes not happen.
Is there a reason why
text/plain;charset=utf-8is synced to
UTF8_STRINGinstead of simply
wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:
The text was updated successfully, but these errors were encountered: