Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dead keys aren't interpreted correctly when typing accented letters (Linux) #7648

Closed
Ansbaradigeidfran opened this issue Jul 12, 2019 · 5 comments

Comments

@Ansbaradigeidfran
Copy link

Version of OpenTTD: 1.9.2

Arch Linux x64 (with XFCE desktop) fully updated as of July 2019
Linux kernel 5.2.0

Expected result

Typing an accented letter (with dead keys) in a text box generates the accented character only
(e.g. AltGr+6, w should generate ŵ, or AltGr+[, e should generate ë)

Actual result

The accent is generated in the text box on the first keypress, and the accented character appears after it on the second keypress
(e.g. AltGr+6, w generates , or AltGr+[, e generates ̈ë)

Steps to reproduce

  • Set OS keyboard layout to "English (UK), variant UK, extended, with Win keys" (same bug is present with "English (US), variant intl. with AltGr dead keys")
  • Start OpenTTD, load a map, and open a window accepting text (e.g. renaming a town or station)
  • Type an accented character into the text field

(Note that some of the upper part of the accents may be obscured by the top of the text box. On closing the text box, the accents are shown in full in the game, but with the error described above.)

On OSX, running an older version (1.6.1), observed behaviour is that on pressing AltGr+6 a silhouetted ? character appears, and then on pressing w it is replaced with a ŵ. I presume this is the intended behaviour.

@kernigh
Copy link
Contributor

kernigh commented Oct 20, 2019

I can't reproduce your problem in OpenTTD 1.9.3 on OpenBSD 6.6 amd64. I changed to layout "English (UK)", "English (UK, extended WinKeys)" in Xfce, Settings, Keyboard. Now AltGr+6 w types ŵ and AltGr+[ e types ë. I can type both ŵ and ë in OpenTTD. There's no "silhouetted ?"; nothing appears until I type both the dead key and the next key.

I'm not sure how your system differs from mine. I haven't changed my font in OpenTTD; I do see ŵ and ë, so the font must have them. I compiled OpenTTD 1.9.3 from source; it uses libSDL from OpenBSD package sdl-1.2.15p10, and ICU libraries from icu4c-64.2p0. I didn't find any keyboard fixes in the changes from OpenTTD 1.9.2 to 1.9.3.

@Ansbaradigeidfran
Copy link
Author

Thank you for attempting to reproduce my error, and explaining the expected behaviour. I now have version 1.9.3 installed, and still find the same faulty behaviour.

I'm using the pre-built Arch package, but rebuilding 1.9.3 from source displays the same issue.

I currently have sdl 1.2.15-13 and icu 64.2-1 installed, so there doesn't appear to be a mis-match there.

I've double-checked that my keyboard settings in XFCE match. Dead keys work in other applications (such as a Terminal window) as expected. localectl reports:
System Locale: LANG=en_GB.UTF-8
VC Keymap: uk
X11 Layout: n/a

If you can suggest any other avenues of investigation, I'd be happy to try them.

@Eddi-z
Copy link
Contributor

Eddi-z commented Oct 21, 2019

I seem to remember an issue where some input method thing intercepted key input and transformed it in unexpected ways, but can't find any reference to it on first glance

@Eddi-z
Copy link
Contributor

Eddi-z commented Oct 21, 2019

i found it, it's #7296

@Ansbaradigeidfran
Copy link
Author

Thanks, Eddi-z. I've downloaded and build the latest nightly build (20191019-master). In this build,the fault is gone, and the dead keys operate as expected. I would therefore conclude that this was a symptom of a bug in SDL 1.2, as described in #7296 , and is now resolved by switching openttd to use SDL 2.0, as detailed in #7086 .

I look forward to the release of OpenTTD 1.9.4 with the above fix!

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

No branches or pull requests

3 participants