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

[Ellis Whitehead]

On Saturday 19 October 2002 23:12, Simon Hausmann wrote:
> 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 ;-)

Btw, using AccelOverride to process shortcut keys isn't a good idea for 
widgets, since it doesn't stop the KeyPress event from occuring.  

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

I'm attaching the patch, in case you want to take a look.  At least it 
compiles...

> > > 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?

A couple of the biggest reason for having actions is for the configurability 
and sparing the programmer the processing of KeyEvents.  The most significant 
conflicts come up when multiple unrelated KParts are embedded at one time.  
Each KPart want's to let its actions have configurable shortcuts, so they use 
KAction (and thus KAccel).

> 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?

Yes, the problem is that KeyPress event is set to 'accept()' be default, so if 
the focus is in a subwidget (say the edit widget of a dialog), then the 
dialog doesn't ever get the KeyPress event to filter.

There are other benefits to having a KAccelEventHandler.  I've been working on  
a significant simplification of the currently complicated kaccel* code, which 
will reduce the line count to about half for KDE 3.2.  This is possible in 
part because KAccelEventHandler allows for unifying more code between KAccel 
& KGlobalAccel and for not having to work around the Qt accelerator id 
paradigm.  That means I can remove most of kaccelbase.* and kaccelaction.*.
Furthermore, it makes it possible to define accelerators which will _only_ be 
activated when the watch widget has focus.  This lets programmers make keys 
which they currently process in keyPressEvent be defined as configurable 
actions.
In KDE 3.2, KAction will handle accelerators of all three scopes (global, 
application, and widget) rather than the programmer having to use different 
classes and APIs for each.  Rather nice, if you ask me. ;)  Anyhow, this 
requires KAccelEventHandler, I think.

Cheers,
Ellis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdecore.patch
Type: text/x-diff
Size: 4594 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021020/f36ffc92/attachment.patch>