[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] fix line edit in ksirc
From:       Ellis Whitehead <ellis () kde ! org>
Date:       2002-11-23 11:44:05
[Download RAW message or body]

On Saturday 23 November 2002 00:33, Simon Hausmann wrote:
> On Sat, Nov 23, 2002 at 01:20:41AM +0100, Ellis Whitehead wrote:
> > On Friday 22 November 2002 19:29, George Staikos wrote:
> > > On Friday November 22 2002 05:15, Simon Hausmann wrote:
> > > > On Fri, Nov 22, 2002 at 12:54:28AM -0500, George Staikos wrote:
> > > > > This patch fixes the lineedit problems I have been seeing in ksirc
> > > > > for quite some time now.  Shift+Backspace was erasing two
> > > > > characters instead of one. This fixes it for me.
> > > > >
> > > > > Ok to apply?
> > > >
> > > > I think that's a workaround for the real bug: the lineedit receives
> > > > multiple accel events for any shift key combination. It's the same
> > > > for shift-left/right for example, and gdb/debug output show the
> > > > same. I remember that this was caused through the global event filter
> > > > changes in kaccel, for which Ellis also applied a fix to solve this
> > > > very problem. But it appears it works only for key events without
> > > > modifiers. Ellis, any idea?
> > >
> > >   Well I think that if we don't get a fix asap, we should commit a
> > > workaround for all the known key problems and deal with the real fix
> > > after 3.1.0.
> >
> > ksirc's method of handling accelerators is very strange.  When I looked
> > at the code a month or so ago, it seemed like the fact that it worked at
> > all must be due to a bug in Qt somewhere. *grin*  I'll check it out again
> > tomorrow to see what I can do...
>
> I very much agree that this part of ksirc's code is pretty fishy,
> but I guess asj had his reasons. In any case I don't feel like
> changing the code not to catch the accel events at this stage. I'd
> be happy to okay George's workaround if the real bug does not get
> forgotten (i.e.  someone files a bugreport) .

The attached patch should fix the problem.  What is Shift+Backspace supposed 
to do though?  It's acting the same as Backspace for me.

Commit?

Cheers,
Ellis
["ksirc.diff" (text/x-diff)]

? ksirc.diff
? KSColourPicker/Makefile.in
Index: ahistlineedit.cpp
===================================================================
RCS file: /home/kde/kdenetwork/ksirc/ahistlineedit.cpp,v
retrieving revision 1.33
diff -u -3 -d -p -b -B -r1.33 ahistlineedit.cpp
--- ahistlineedit.cpp	2002/02/19 21:12:46	1.33
+++ ahistlineedit.cpp	2002/11/23 11:39:55
@@ -58,6 +58,7 @@ void aHistLineEdit::processKeyEvent( QKe
   // we get some key-events via QEvent::AccelOverride. By accept()ing them,
   // we prevent accels being fired.
   bool accept = true;
+  bool callKeyPressEvent = false;  
 
   if ( e->key() != Key_Tab && e->key() != Key_Shift)
     emit notTab();
@@ -98,8 +99,7 @@ void aHistLineEdit::processKeyEvent( QKe
       setCursorPosition(curPos + 2);
       break;
     default:
-      KLineEdit::keyPressEvent(e);
-      accept = false;
+      callKeyPressEvent = true;
     }
   }
   else if(e->state() == 0){
@@ -148,17 +148,24 @@ void aHistLineEdit::processKeyEvent( QKe
       current = hist.fromLast(); // set current history item back to the last item in the list 
       // no break - Fall through on purpose!
     default:
-      KLineEdit::keyPressEvent(e);
-      accept = false;
+      callKeyPressEvent = true;
     }
   }
-  else{
-    KLineEdit::keyPressEvent(e);
+  // QLineEdit falsely converts Alt+C to the character 'c', so to work around
+  //  this, we just don't pass any Alt+? key on to the keyPressEvent() method.
+  else if ( (e->state() & AltButton) == 0 ) {
+    callKeyPressEvent = true;
+  }
+  else {
     accept = false;
   }
   
-  if ( accept )
+  if ( accept ) {
     e->accept();
+    if ( callKeyPressEvent ) {  
+      KLineEdit::keyPressEvent(e);
+    }
+  }
 }
 
 void aHistLineEdit::ColourPickerPopUp()


[prev in list] [next in list] [prev in thread] [next in thread]