Version: 0.70.0 (using 4.2.00 (KDE 4.2.0) "release 83.1", KDE:KDE4:Factory:Desktop / openSUSE_11.1) Compiler: gcc OS: Linux (x86_64) release 2.6.27.7-9-default I run KDE 4.2 with pt-BR input (LC_CTYPE="pt_BR.UTF-8"). I have set up my chat window policy to group all incoming messages to the same chat window. My keyboard layout is br-abnt2 (the one with ç) If I start a first chat tab, then I start a second chat tab, the first tab (left-most) looses its accentuation capacity. I.E.: if I want to type 'ã', the usual way is to hit '~', then 'a'. But instead of 'ã', I get '~a', as If I have lost the internationalization capacity. The same happens if I try to type 'à', 'ò', 'ê', 'ñ' or any other character that needs a key combination. The same does not happen If I type 'ç', because it a is unique character on my keyboard. The funny thing is that this behaviour happens only at the left-most tab. But it starts to happen only after I have a second tab. I.E., if I start the chat window with a single tab, I will not happen until I have second tab. But since I have a second tab, if I close the first one, and then the second one becomes the first one, then it will have the same problem. I guess it doen't matter the protocol, because I have faced the problem with both Windows Live Messanger and Jabber/Gtalk.
I was debugging this bug but didn't find out how to fix it yet. It looks like the problem is in the ChatView reparenting or something like that, because if I comment out the view->show(); in KopeteChatWindow::setPrimaryChatView and create second tab then the accents can be writen in first tab. The workaround is to check "Always show tabs" in configure->behavior->chat
*** Bug 180490 has been marked as a duplicate of this bug. ***
This happens in ALL text inputs in Kopete, including in the main window and the configuration dialog. This makes Kopete communication very hard in any language other than English, unusable for some. I'm raising the severity of this bug.
SVN commit 922100 by thiago: Move this code into a K_GLOBAL_STATIC. There are two problems with this code: The first is that it calls i18n() before KLocale and KComponentData have initialised. That means we never get any translation. The second is that it causes the QIconvCodec in Qt to initialise before the locale system in libc is initialised (that's done inside QCoreApplication's constructor). This means this thread is confined to ASCII, thereby causing all X11 key translations to be broken. This sounds like a solution to bug 182996, but my symptom was wildly different: I had the problem in any and every text input. Please retest the bug's symptom and close if it's fixed. CCBUG:182996 M +24 -10 kopeteutils.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=922100
Apparently this didn't fix it, but my issue is gone. Re-lowering the priority
Ok new information. The accents don't work because in QXIMInputContext::x11FilterEvent (qt/src/gui/inputmethod/qximinputcontext_x11.cpp) the XFilterEvent(event, keywidget->effectiveWinId()) returns false (it returns true when accents are printed correctly). So now the question is why XFilterEvent doesn't work.
It's Qt bug was reported to TT, will assign ID when I get it
The TT bug number is 244337.
SVN commit 925685 by rjarosz: Backport thiago's commit 922100. CCBUG:182996 M +24 -10 kopeteutils.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=925685
*** Bug 184678 has been marked as a duplicate of this bug. ***
*** Bug 174451 has been marked as a duplicate of this bug. ***
*** Bug 185557 has been marked as a duplicate of this bug. ***
Same problem for me (Kubuntu Intrepid KDE 4.2.1)
According to Qt TT, this is fixed and should be in some 4.5.x Qt release (most likely next). I'll will close this when Qt with this fix is released.
Fixed in Qt 4.5.1
*** Bug 192690 has been marked as a duplicate of this bug. ***
*** Bug 195155 has been marked as a duplicate of this bug. ***
*** Bug 195965 has been marked as a duplicate of this bug. ***