accel problems: might be qt-copt, might be kdelibs

[Simon Hausmann]

On Sat, Oct 19, 2002 at 11:01:50PM +0200, Ellis Whitehead wrote:
> On Saturday 19 October 2002 17:32, Simon Hausmann wrote:
> > On Sat, Oct 19, 2002 at 04:55:43PM +0200, Simon Hausmann wrote:
> > > On Wed, Oct 16, 2002 at 01:17:12AM +0200, Ingo Klöcker wrote:
> > > > On Tuesday 15 October 2002 22:23, Ellis Whitehead wrote:
> > > > > On Tuesday 15 October 2002 10:28, Matthias Ettrich wrote:
> > > > > > On Monday 14 October 2002 22:45, Ellis Whitehead wrote:
> > > > > > > > The problem in konqy still exists.
> > > > > > > > Pressing alt+left goes back and activates the menubar, which
> > > > > > > > then can't be deactivated using Escape.
> > > > > >
> > > > > > There were some problems in Qt, they will hopefully go away with
> > > > > > the next beta.
> > > > > >
> > > > > > Matthias
> > > > >
> > > > > So Marc, Alexander, Ingo, David: shall I commit the patch?  It fixes
> > > > > the KMail problem Marc initially mentioned.
> > > >
> > > > Well, if your patch doesn't break other things than please commit.
> > >
> > > Unfortunately the patch breaks ksirc, quite bad. KSirc's lineedit
> > > listens for AccelOverride events and based on those processes keys.
> > > With the patch the lineedit receivers two AccelOverride events for
> > > one keypress. You can imagine the effect ;-)
> 
> The double-evoking of AccelOverride is an unfortunate side-effect of the event 
> filter.  I've written a small patch for the problems you've mentioned, but I 
> can't test it till kdecore links for me again ('make' problems in current 
> cvs, apparently).  I'll post the patch once it's working again.

Great! (that you have a patch, not that kdecore doesn't build :)

> > This event filter make me wonder: What is it that is so broken in Qt
> > that KDE has to re-invent the whole wheel and handle X11 key events?
> 
> It's not that Qt is broken, but rather that it wasn't designed to support the 
> KPart paradigm.  An accel is global within a Qt application, and we can't 
> give certain accels more priority over others (such as giving the KPart with 
> focus priority over a second visible KPart that doesn't have the focus).

I wonder why an accelerator is used then. If the activation depends
on whether the part has the focus or not (and I agree with that
behaviour) then I think the right thing is to listen for regular key
events. Isn't that what the idea behind key events and focus
handling?

If this is about actions then I think the actioncollection should
simply listen for key events on the part's widget and catch action
shortcuts appropriately.

Or does that miss any case?

Simon