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

List:       kde-core-devel
Subject:    Re: KXMLGUIClient
From:       Ellis Whitehead <kde () ellisw ! net>
Date:       2002-01-14 22:12:34
[Download RAW message or body]

Hi there Waldo,

I'm afraid that the  problem isn't entirely fixed with David's patch.  I was 
able to get to the root of it on my local cvs copy when I got back home on 
Saturday night, but I'll have to wait to commit it until Friday since it's 
not BC.

The KAccel warnings in konsole are a different issue.  I'll look into it and 
surely have it fixed when I commit the rest of the stuff on Friday.

Regards,
Ellis

On Monday 14 January 2002 16:38, Waldo Bastian wrote:
> On Tuesday 01 January 2002 05:57 pm, Ellis Whitehead wrote:
> > On Tuesday 01 January 2002 07:31 pm, Waldo Bastian wrote:
> > > On Tuesday 01 January 2002 03:16 pm, Ellis Whitehead wrote:
> > > > Hi guys,
> > > >
> > > > I believe I've figured out an elegant solution to the KAccel problems
> > > > I've been having with KAction -- but it would require that
> > > > KXMLGUIClient know which QWidget* it's a part of, so that it can pass
> > > > that pointer to "new KActionCollection()", so that actions created on
> > > > that collection are not all placed in one single monolithic
> > > > top-level-window KAccel object full of key conflicts.
> > >
> > > I think the reason for lumping them together is that otherwise
> > > keybindings don't work when e.g. the menubar isn't visible.
> > >
> > > Of course, the accels for a file-open dialog shouldn't end up in e.g.
> > > kedit's mainwindow, but should be collected in the mainwindow of the
> > > file-dialog itself. Could that be what is going wrong?
> >
> > Yes, that's exactly what's going wrong.  This causes a number of
> > problems. One of which is that the KApplication-KAccel object is the
> > first created, and is thus the last queried for shortcut keys.  So when a
> > new window pops up, but puts its shortcuts into the bottom-level
> > accelerator collection, it may be blocked by a QAccel object created
> > after the original KAccel object, by a QPopupMenu object for example.
>
> Has this been fixed already? David suggested a patch for this to prevent
> that accels end up in the wrong window.
>
> Also when starting e.g. konsole I get a bunch of warnings like these:
> kdecore (KAccel): WARNING: KAction::plugAccel( kacc = 0x8114448 ): KAccel
> object already contains an action name "unnamed"
>
> Which somehow seems to be related.
>
> Cheers,
> Waldo

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