Bug 179205

Summary: In single line entry fields keys combined with CTRL are executed twice
Product: [Unmaintained] kdelibs Reporter: kgw
Component: kdeuiAssignee: kdelibs bugs <kdelibs-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: aacid, finex, kdedevel, modax, mpyne, pano_90, projects.gg.aaron, richard.bos
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Unspecified   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description kgw 2008-12-31 13:54:03 UTC
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.
Comment 1 FiNeX 2008-12-31 13:58:50 UTC
Confirmed in current trunk r903695.
(reproduced in krunner and kmail too)
Comment 2 FiNeX 2008-12-31 15:45:38 UTC
*** Bug 179212 has been marked as a duplicate of this bug. ***
Comment 3 Dario Andres 2009-01-03 18:07:41 UTC
*** Bug 179501 has been marked as a duplicate of this bug. ***
Comment 4 Simon St James 2009-01-04 00:01:32 UTC
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.
Comment 5 Michael Pyne 2009-01-04 06:12:01 UTC
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.
Comment 6 Michael Pyne 2009-01-04 07:21:45 UTC
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
Comment 7 Albert Astals Cid 2009-01-04 18:18:54 UTC
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.
Comment 8 Richard Bos 2009-01-04 20:49:16 UTC
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.
Comment 9 Albert Astals Cid 2009-01-04 20:52:45 UTC
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.
Comment 10 kgw 2009-01-04 22:24:16 UTC
@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.
Comment 11 Albert Astals Cid 2009-01-04 22:30:16 UTC
Good then :-)
Comment 13 Pino Toscano 2009-01-05 13:00:14 UTC
*** Bug 179695 has been marked as a duplicate of this bug. ***