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

[Ellis Whitehead]

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.

> And this new KAccel x11 event filter breaks more: It allows to
> activate shortcuts that are disabled.

Ditto above.

> 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).

> Is it something that can possibly be fixed in Qt? Did anyone report
> the problem, yet?

I plan to submit a qapplication.cpp/qaccel.cpp patch once I've figured out a 
more elegant way to handle customizing accelerator handing.  Until then, 
there's not really anything useful to report.

> (sorry for the provocative question :)

 No problem. ;)

Regards,
Ellis