search

swaywm / wlroots

A modular Wayland compositor library
https://gitlab.freedesktop.org/wlroots/wlroots/
MIT License
2.15k stars 343 forks source link

[Feature Request] Clipboard: set "text/plain;charset=utf-8" on the xwayland side if exposed by the source #1839

Open zickgraf opened 5 years ago

zickgraf commented 5 years ago

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 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:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1839

emersion commented 5 years ago

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.

zickgraf commented 5 years ago

Thanks for the quick reply! :-)

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"?

emersion commented 5 years ago

If the source exposes text/plain;charset=utf-8, we should just use that. If not, we should fallback to UTF8_STRING.

zickgraf commented 5 years ago

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 commented 4 years ago

In case people are looking for this: there is a closed upstream report and multiple downstream reports.