179205 2008-12-31 13:54:03 +0000 In single line entry fields keys combined with CTRL are executed twice 2009-01-05 13:00:14 +0000 1 1 10 Unmaintained kdelibs kdeui unspecified Compiled Sources Unspecified RESOLVED FIXED NOR normal --- 1 kgw kdelibs-bugs-null aacid finex kdedevel modax.reg mpyne pano9000 projects.gg.aaron richard.bos 0 oldest_to_newest 690027 0 kgw 2008-12-31 13:54:03 +0000 Version: (using Devel) Installed from: Compiled sources Key combinations such as CTRL-V and CTRL-<Left arrow key> and CTRL-<Right arrow key> are all executed twice. 690033 1 finex 2008-12-31 13:58:50 +0000 Confirmed in current trunk r903695. (reproduced in krunner and kmail too) 690141 2 finex 2008-12-31 15:45:38 +0000 *** Bug 179212 has been marked as a duplicate of this bug. *** 693259 3 andresbajotierra 2009-01-03 18:07:41 +0000 *** Bug 179501 has been marked as a duplicate of this bug. *** 693438 4 kdedevel 2009-01-04 00:01:32 +0000 I've grabbed some installs from my archives, and I can't reproduce with trunk at revision 902831, but I can with 903483 and later, so it was probably introduced somewhere between these. 693562 5 mpyne 2009-01-04 06:12:01 +0000 Seems to be related to changes introduced in revision 902991 ( http://websvn.kde.org/?view=rev&revision=902991 ). The keyReleaseEvent() handler does a lot of actions on each non-action keypress, I suspect somehow that it playing with its internal logic. I'll try looking at it to see what's going on. 693564 6 mpyne 2009-01-04 07:21:45 +0000 SVN commit 905299 by mpyne: Revert commit 902991 (and a related BC-maintaining commit which is now unnecessary). This commit was intended to improve support for accented characters from what I gather but it moved the keyPress event handler to act on key release instead which is causing bug 179205 (KLineEdits have actions using Ctrl key duplicated twice). This is because pasting on key release doesn't stop Qt from pasting on key press (and we can't just disable various Qt actions on key press as that's really an implementation detail for Qt IMO). I'm sure there is a way to implement the accented chars thing that makes everyone happy but I'd rather fix the more pressing bug at this point. CCMAIL:ereslibre@kde.org BUG:179205 M +12 -26 klineedit.cpp M +0 -7 klineedit.h WebSVN link: http://websvn.kde.org/?view=rev&revision=905299 693931 7 aacid 2009-01-04 18:18:54 +0000 I'm not sure duplicate Ctrl events are more important than the inhability of writting accents, everybody writes accents, just power users use Ctrl key. 694060 8 richard.bos 2009-01-04 20:49:16 +0000 People that work on both linux -and- MS windows will use <ctrl>C and <ctrl>V. The latter always works in MS.... So, not only power users will use the <ctrl> key sequence. If <ctrl> key sequences are not working people (migrating) from the other platform will be disappointed, not the best way to keep people on linux. 694061 9 aacid 2009-01-04 20:52:45 +0000 People that work on both linux -and- MS windows will use accents, how i'm supposed to write "balcón" without them? If accents are not working people (migrating) from the other platform will be disappointed, not the best way to keep people on linux. That unless the accents thing is for shortcuts with accents, that is something like Ctrl+ó which i can agree on being less important. 694121 10 kgw 2009-01-04 22:24:16 +0000 @Albert, accents do work after the reverted patch, I have looked at the code and it seems to be wrong in the case of accented characters as well which I just confirmed: You can't enter accented characters with commit 902991 in place. 694128 11 aacid 2009-01-04 22:30:16 +0000 Good then :-) 694143 12 mpyne 2009-01-04 22:54:14 +0000 Reported as Qt bug 239918 http://trolltech.com/developer/task-tracker/index_html?method=entry&id=239918 694446 13 pino 2009-01-05 13:00:14 +0000 *** Bug 179695 has been marked as a duplicate of this bug. ***