apprt/gtk: (clipboard) fix GTK internal paste of UTF-8 content (#9710)
When pasting text in GTK, the current version properly prioritizes text/plain;charset=utf-8 when the content is offered by another application, but when pasting from ghostty to itself the mime type selection algorithm prefers the offer order and matches `text/plain`, which then converts non-ASCII UTF-8 into a bunch of escaped hex characters (e.g. 日本語 becomes \E6\97\A5\E6\9C\AC\E8\AA\9E) This is being discussed on the GTK side[1], but until everyone gets an updated GTK it cannot hurt to offer the UTF-8 variant first (and one of the GTK dev claims it actually is a bug not to do it, but the wayland spec is not clear about it, so other clients could behave similarly) Link: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9189 [1] Fixes #9682pull/9713/head
commit
d9529947a4
|
|
@ -3373,12 +3373,16 @@ const Clipboard = struct {
|
|||
// text/plain type. The default charset when there is
|
||||
// none is ASCII, and lots of things look for UTF-8
|
||||
// specifically.
|
||||
// The specs are not clear about the order here, but
|
||||
// some clients apparently pick the first match in the
|
||||
// order we set here then garble up bare 'text/plain'
|
||||
// with non-ASCII UTF-8 content, so offer UTF-8 first.
|
||||
//
|
||||
// Note that under X11, GTK automatically adds the
|
||||
// UTF8_STRING atom when this is present.
|
||||
const text_provider_atoms = [_][:0]const u8{
|
||||
"text/plain",
|
||||
"text/plain;charset=utf-8",
|
||||
"text/plain",
|
||||
};
|
||||
var text_providers: [text_provider_atoms.len]*gdk.ContentProvider = undefined;
|
||||
for (text_provider_atoms, 0..) |atom, j| {
|
||||
|
|
|
|||
Loading…
Reference in New Issue