Bug #1248

Character keys outside of latin1 codepage cannot be bound

Added by MrBougo almost 2 years ago. Updated 11 months ago.

Status:NewStart date:06/15/2012
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Engine
Target version:0.8

Description

First of all, DarkPlaces does not recognize non-ASCII symbols in the console as first argument for the bind command. For example, bind é foo outputs "é" isn't a valid key if utf8_enable is 1 and outputs nothing if it's set to 0, but the bind does not work (the character showing in the console when é is typed is part of the special font characters). Moreover, those keys cannot even be bound in the menu, it complains that "<UNKNOWN KEYNUM>" isn't a valid key (regardless of utf8_enable).

This can be worked around for character keys in the latin1 range through the use of a latin1-encoded configuration file with lines such as bind é foo. This hack has the potentially confusing consequence of binds overlapping. Nevermind. See freenode/#xonotic Aug 01 2012 9:30 UTC.

The real problem comes with characters that are not in the latin1 range. Slovak keyboards, for example, have a numerical key row that consists almost entirely of accented characters that are not in the latin1 codepage and are thus not bindable at all. I guess cyrillic keyboards are not usable at all either. This is kind of a big deal.

I put this issue in the "engine" category, but it also affects the menu.

Relevant forums.xonotic threads:

In French and Belgian keyboards numbers are on shift level. The corresponding non-shift level has characters such as é, à, ç, ... all in the latin1 range.

keys.diff Magnifier (6.24 KB) divVerent, 08/01/2012 12:08 pm

History

#1 Updated by MrBougo almost 2 years ago

  • Assignee set to divVerent

Sorry div for assigning it to you, feel free to reassign to somebody else if needed. Somebody needs to see this.

#2 Updated by divVerent over 1 year ago

  • Assignee deleted (divVerent)

Can't do much about this. This would need a major (as in, complete rewrite) of keyboard support in DP.

Americans should be banned from writing code. They never think about i18n.

#3 Updated by MrBougo over 1 year ago

Ow. What can we do about this then? Show a warning message in the menu suggesting QWERTY when the language is set to a cyrillic-based one? Add a FAQ item to the site and documentation? Put it in a README?

Because right now, Xonotic "just doesn't work" for cyrillic layouts.

#4 Updated by divVerent over 1 year ago

Russians typically (or rather, ALWAYS) have some keybind to switch to US layout.

Fixing this would basically require turning ALL MAX_KEYS sized arrays into hashtables. Not an easy task at all. Once that's done, the special keys can be remapped from 127 upwards to 0x1000000 upwards and we're good.

#5 Updated by divVerent over 1 year ago

I tried to make a patch that synthesizes keycodes if only ascii code is given (which is the case with the international keys). It works with GLX, and fails horribly with SDL (keys never get released). It looks to me like this is the wrong approach...

#6 Updated by Mirio 11 months ago

  • Target version set to 0.8

Also available in: Atom PDF