Opened 11 years ago

Closed 11 years ago

#68 closed defect (fixed)

Dead keys are not processed correctly

Reported by: Dmitry A. Kuminov Owned by:
Priority: blocker Milestone: Qt Beta 2
Component: QtGui Version: 4.5.1 Beta 1
Severity: Keywords:


Dead keys (ones intended to produce composite characters) are not correctly processed by Qt at the moment.

Change History (7)

comment:1 Changed 11 years ago by Dmitry A. Kuminov

Priority: majorblocker

Setting this as the Beta 2 blocker as well though it makes it little bit harder to fit the deadline.

comment:2 Changed 11 years ago by Dmitry A. Kuminov

Studied how dead keys work a bit. The table below summarizes the standard behavior on Vista and eComStation.

          what pressed?
          dead key          | valid letter         | invalid letter
Windows | nothing happens   | prints composite     | prints accent then
        |                   |                      | letter
OS/2 PM | prints accent,    | replaces accent with | removes accent
        | cursor stays back | composite, advances  |
        |                   | cursor               |

Qt on Windows behaves just the same as the native applications. Apparently, it makes sense to do the same on OS/2: behave in Qt like the system does it in native.

comment:3 Changed 11 years ago by Dmitry A. Kuminov

The only problem is that it's not practically possible to implement the "prints accent, cursor stays back" behavior in Qt because there is no support for such sort of things: we would have to introduce a special Qt keyboard event flag indicating a dead key and implement support for this flag in every widget that accepts keyboard input.

It may seem that as a safe alternative we may send a series of "print accent", "cursor left" events followed by "delete", "print composite" (if valid) or just "delete" (otherwise) but imagine if there is a custom widget that only accepts key presses but ignores cursor moves and editing keys: it would get a totally unexpected "accent" character. So, not an option too.

So, I will do it as follows:

          what pressed?
          dead key          | valid letter         | invalid letter
OS/2 PM | nothing happens   | print composite      | nothing happens

Silvan, is that accepatble for people with dead keys in the keyboard layouts?

comment:4 Changed 11 years ago by Dmitry A. Kuminov

I've actually found a more clever way. Qt has a set of special values for dead keys, they start with the Key_Dead_ prefix, for example: Qt::Key_Dead_Diaeresis, Qt::Key_Dead_Circumflex and so on. We may translate dead keys to these codes but set the text() field in QKeyEvent to a null string for them.

This way, the keys will still be seen by Qt (as opposed to the previous suggestion where all dead keys'd have been completely hidden from it) but won't be printed (because text() is null). Similarly, for invalid composite characters we will reset text() to null to have the keys still reported but avoid generating characters (to match the native behavior).

More over, using this approach sophisticated widgets may detect dead keys in a platform-independent manner (using normal Qt means, i.e. the QKeyEvent::key() field) and properly visualize them if needed.

I will implement it this way.

comment:5 Changed 11 years ago by Dmitry A. Kuminov

Done in r179. Silvan, please test and comment.

comment:6 Changed 11 years ago by Silvan Scherrer


i did some tests with it.
First i tested with LANG = de_CH , with this it did not work
then i tested with LANG = de_CH.IBM850 , and with this it worked as on PM

so somehow it seems that the codepage is not right detected with the short LANG env.

comment:7 Changed 11 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: newclosed

That's expected. When the code page is not explicitly specified, Qt selects iso-8859-1 (=IBM819) for most western locales which doesn't match IBM850 that you have set on OS/2. Anyway, this is unrelated to dead keys, see #49 for details. Closing this defect.

Note: See TracTickets for help on using tickets.