Dead keys no longer dead in GTK applications (still working fine in Qt applications)

I just had a small update after which dead keys no longer work as intended in Firefox or Signal, but they still do in Dolphin and Falkon, leading me to believe it has to do with the update of gtk3.

Relevant part of pacman.log:

[2021-03-27T17:45:07+0100] [ALPM] upgraded gtk3 (1:3.24.27-4 -> 1:3.24.28-1)
[2021-03-27T17:45:07+0100] [ALPM] upgraded eos-bash-shared (1.6.8-1 -> 1.6.10-1)
[2021-03-27T17:45:07+0100] [ALPM] upgraded tracker3 (3.0.3-1 -> 3.1.0-1)

Keyboard is set to US International with dead keys.

Unsure how to proceed from here…

What’s dead keys?

Think diacritical marks.

1 Like

This post describes a similar situation and offers a solution for Arch:

1 Like

Hmm, seems diacritics still work, but single and double quotation marks for example look completely different now, which threw me off. Still not sure if it´s (see what I mean?) as it should be though…

I´ll give that a read, thank you.

Edit: seems that’s more about the underline, which is indeed also annoying as hell, so I’ll give that a go and see what that does. However, what I meant was I noticed how the quotation marks suddenly look differently. Compare the “it’s” in this post, written from Falkon, with the same in my post right above this one, written from Firefox. It’s subtle, but it’s there…

1 Like

Hmm.

$ yay -S gtk3-no_deadkeys_underline
:: Checking for conflicts...
:: Checking for inner conflicts...
 ->
Package conflicts found:
 -> Installing gtk3-no_deadkeys_underline will remove: gtk3, gtk3 (gtk3-print-backends)
 -> Conflicting packages will have to be confirmed manually
[Repo Make:13]  python-markupsafe-1.1.1-7  python-beaker-1.11.0-6  python-mako-1.1.4-1  gobject-introspection-1.68.0-1  glib2-docs-2.68.0-5  python-lxml-4.6.2-2  python-pygments-2.8.1-1  python-anytree-2.8.0-3  gtk-doc-1.33.2-1  libsass-3.6.4-1  sassc-3.6.1-2  ninja-1.10.2-1  meson-0.57.1-1
[Aur:1]  gtk3-no_deadkeys_underline-1:3.24.27-4

==> Remove make dependencies after install? [y/N]

Wants to remove gtk3 entirely. Not so sure this is what I want…

Yes, I see what you mean. In your examples you’re getting

it´s

when you expect

it’s

It’s probably not what you want. As you point out, that solution is solving a different problem.

In your case, it looks like the gtk3 update may have introduced an incorrect mapping in the GTK Dead Key Compose Table:

https://help.ubuntu.com/community/GtkDeadKeyTable

While probably not directly relevant to the current problem, I see that a few days ago the GTK development team posted an article about recent changes to how GTK implements dead key functionality:

https://blog.gtk.org/2021/03/24/input-revisited/

1 Like

I quite like how the new dead keys work in GTK3. What I dislike is that the underlined character is not really there, so when I move my cursor it gets deleted, that’s a bit inconsistent. And the fact Qt applications behave differently, that’s annoying as well.

I somewhat wish I could have the proper dead key behaviour consistently in GTK3 and Qt applications, like on an old TTY: when I press a dead key, it should display the character to the right of my cursor, and only advance the cursor when I press another key.

On a (tele)typewriter, when you press a key like A, two things happen: letter a is printed on the paper and the carriage advances one character to the right, so that when you press another key, it gets printed next to it. With dead keys, like the umlaut dots ¨, the character ¨ is printed on the paper, but the carriage stays in place, so that when you type, for example A, it gets printed in the same place so you get a combination of both characters: ä.

That’s why they are called dead keys, because they do not advance the carriage on a (tele)typewriter.

And yes, getting ’ after pressing ´           is a bug. It should type ´, which it does when you press ´´. I expect that will get fixed in the next update.

1 Like