[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-02 1:57:17
[Download RAW message or body]

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.

So the issue is that we need each KActionCollection to create a unique KAccel 
object.  For this it needs to have a QWidget* to attach to.  Unless I hear 
objections, I'll probably commit a patch tonight which will break compilation 
(but not BC) on construction of a KActionCollection object with no parent 
passed.  In most cases, the fix will be:
	-new KActionCollection;
	+new KActionCollection( this ); 
or
	+ m_actionCollection( this )
		in the initializer list of the constructor.

A grep of "new KAccelCollection" in the following modules shows that all calls 
pass a parent pointer.

kdeaddons  kdeartwork  kde-common  kdegraphics  kdemultimedia  kdepim 
kdesupport  kdevelop kdeadmin   kdebase     kdegames    kdelibs     
kdenetwork     kdesdk  kdeutils

Output is in the attached text file.
["KActionCollection.txt" (text/plain)]

kdegraphics/kghostview/kgv_view.cpp:    statedep = new KActionCollection( this, \
                "statedep", KGVFactory::instance() );
kdegraphics/kghostview/kgvshell.cpp:    statedep = new KActionCollection( this, \
                "statedep" );
kdegraphics/kamera/kcontrol/kamera.cpp:	m_actions = new KActionCollection(this);
kdegraphics/kuickshow/src/imagewindow.cpp:    m_actions = new KActionCollection( this \
                );
kdemultimedia/kmix/kmixerwidget.cpp:   m_actions = new KActionCollection( this );
kdemultimedia/kmix/mixdevicewidget.cpp:   m_actions = new KActionCollection( this );
kdepim/empath/parts/libEmpathComposeWidget/EmpathAttachmentListWidget.cpp:    \
                actionCollection_ = new KActionCollection(this, "actionCollection");
kdepim/empath/parts/libEmpathComposeWidget/EmpathComposeWidget.cpp:    \
                actionCollection_ = new KActionCollection(this, "actionCollection");
kdepim/empath/ui/EmpathUI.cpp:    actionCollection_ = new KActionCollection(this, \
                "actionCollection");
kdepim/twister/ui/TwisterUI.cpp:    actionCollection_ = new KActionCollection(this, \
"actionCollection");



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