[Bug] Accels in KActionMenus aren't enabled by KParts::MainWindow::createUI()

[David Faure]

On Saturday 31 January 2004 15:00, Ingo Klöcker wrote:
> Hi,
> 
> see http://bugs.kde.org/show_bug.cgi?id=70459 for a real world example. 
> Additionally the attached patch (applied to kdelibs/kparts/tests) 
> demonstrates the bug. As long as part 2 hasn't been activated the 
> shortcut for "Part 1's Menu->Blah" (which is 'a') and the shortcut for 
> "Part 1's Menu->Foo->Bar" (which is 'f') both work. Now activate part 2 
> and then reactivate part 1. You can now verify that 'a' is still 
> working but that 'f' doesn't work anymore.

I see the problem.
With a normal KAction, plug() is called again when reactivating the part.

But with a KActionMenu, the action is plugged into the popup-menu only once, after that
it's the KActionMenu itself that's plugged/unplugged, so nothing is calling plugShortcut()
for the actions in the KActionMenu.

The problem is that KActionMenu has no idea which actions are plugged into it,
it simply offers a QPopupMenu and lets them plug into it (I see a big design problem
here, but OTOH I'm not sure how to fix it even in kde4).

So I see three solutions (rather, three ways to go from there, no real solution yet) :

* not using KActionMenu (but explicitly listing the actions in a submenu in the XMLGUI file.
This uses a KActionMenu internally IIRC, but the actions will be plugged/unplugged from it,
so things will work as expected).

* fixing/redesigning KActionMenu to know its actions, to call plugShortcut() on them.

* fixing this at the Qt level. I'm not sure about the interactions between QAccel and
KAccel... We're plugging a popupmenu with accels on its items, so obviously KAccel
doesn't see those. Ellis: do you see a solution?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).