Skip to content
This repository was archived by the owner on Nov 1, 2021. It is now read-only.

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

Open
zickgraf opened this issue Sep 30, 2019 · 5 comments

Comments

@zickgraf
Copy link

zickgraf commented Sep 30, 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 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
Copy link
Member

emersion commented Oct 1, 2019

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
Copy link
Author

zickgraf commented Oct 1, 2019

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
Copy link
Member

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

@zickgraf
Copy link
Author

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 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
@zickgraf
Copy link
Author

zickgraf commented Feb 8, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants