[Qt-interest] keyPressEvent() confusion with dead keys/accents correctly

[Nikos Chantziaras]

Basically, I ran across this exact same problem:

http://www.qtcentre.org/threads/4653-Handling-of-dead-keys-in-keyPressEvent%28%29

   I want to capture key presses, including dead keys.
   So for instance, if you press ~ and afterwards n,
   you get ñ (at least on a Spanish keyboard layout).

   When I reimplement keyPressEvent() in my widget, I
   get however always the ~ and n separately. I would
   rather get only one keyPressEvent() with the
   complete character.

On his system it was a keyboard layout problem.  However, I don't have 
keyboard layout problems and other Qt applications work correctly in 
this regard (I can input accents correctly in Creator for example, or 
any demo app that comes with Qt, or any other Qt app I have installed on 
my system, including the whole of KDE.)  So it seems I'm doing it wrong 
in my keyPressEvent()?

My keyPressEvent() receives dead keys.  AFAIK, it shouldn't receive them 
in the first place, because when compiling the application for Windows, 
it doesn't.  It does only on Linux.  Furthermore, if I ignore dead keys 
with something like:

   if (e->key() >= Qt::Key_Dead_Grave && e->key() <= Qt::Key_Dead_Horn) {
       QScrollArea::keyPressEvent(e);
       return;
   }

then I get rid of the problem of printing dead keys, but the next key 
event I get still does not contain the correct, accented character in 
its e->text().  It contains the unaccented one.

Turning on key compression with setAttribute(Qt::WA_KeyCompression) does 
not help.

Studying the source code of QTextEdit and its keyPressEvent() 
implementation didn't turn up anything useful either.

My keyPressEvent() implementation can be simplified to this:

   if (e->text().isEmpty() || !e->text().at(0).isPrint()
       || (e->key() >= Qt::Key_Dead_Grave
           && e->key() <= Qt::Key_Dead_Horn))
   {
       QScrollArea::keyPressEvent(e);
       return;
   }

   qDebug() << e->text()

In this implementation, qDebug will *never* print a "ñ".  It's always 
just "n".