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

List:       kde-core-devel
Subject:    [PATCH] Re: KDE/kdelibs/kdeui/xmlgui
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2009-01-02 12:47:47
Message-ID: 200901021347.48326.kossebau () kde ! org
[Download RAW message or body]

Hi Urs and all,

Am Freitag, 2. Januar 2009, um 00:29 Uhr, schrieb Friedrich W. H. Kossebau:
> Am Mittwoch, 31. Dezember 2008, um 12:53 Uhr, schrieb Urs Wolfer:
> > I hope sombody comes up with a better fix. Otherwise it's to decide what
> > to do:
> > #1: revert both KBookmarkmanager and my ui_standards.rc commit and thus
> > break shortcut configuration for all bookmark feautures in every app
> > again.
> >
> > #2: test this change with all known apps which use bookmark feature. I
> > have done that already, but most probably forgot some. Fix it if a app
> > would be broken (Okteta is the only known so far).
> >
> > What is your proposal?
>
> To take half an hour, then one more, and another one, and find the source
> of the problem, with another pair of eyes ;)
>
> KBookmarkMenu calls KActionCollection to create a standard action, but with
> own identifier, e.g "add_bookmark" instead of "bookmark_add".
> KActionCollection now calls KStandardAction::create(), before it sets the
> given identifier and adds the created action to its list. But
> KStandardAction now perhaps tries to be too smart: After creating the
> standard action, including the default identifier, it sees if the parent is
> a
> KActionCollection and then adds it to it, with the default identifier.
> Which in the case of bookmark_add and bookmark_edit triggers the creation
> of the default Bookmarks menu. Fail.

Please try the attached patch.
It tries to solve the problem by just passing 0 as parent to 
KStandardAction::create(). As with all action classes which are created by 
KStandardAction::create() the parent seems just to be used only for Qt's 
garbage control. So this should be theoretically no problem. With 0 as parent 
KStandardAction::create() now does not add the new action to the collection 
itself. And practically I found no problem, too, e.g. with Okular, Konqueror 
and Konsole. And Okteta :P

So if this patch works for you all, it should be committed and your 
ui_standards.rc commit, Urs, can be reverted :)

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta

["fixAddActionWithNondefaultNameId.patch" (text/x-diff)]

Index: kdelibs/kdeui/actions/kactioncollection.cpp
===================================================================
--- kdelibs/kdeui/actions/kactioncollection.cpp	(Revision 904453)
+++ kdelibs/kdeui/actions/kactioncollection.cpp	(Arbeitskopie)
@@ -344,7 +344,10 @@
 KAction *KActionCollection::addAction(KStandardAction::StandardAction actionType, \
                const QString &name,
                                       const QObject *receiver, const char *member)
 {
-  KAction *action = KStandardAction::create(actionType, receiver, member, this);
+  // pass 0 as parent, because if the parent is a KActionCollection \
KStandardAction::create automatically +  // adds the action to it, but using the \
default name, so the action would exist two times in the collection. +  KAction \
*action = KStandardAction::create(actionType, receiver, member, 0); +  \
action->setParent(this);  // Reset the objectName so we don't trigger the warning \
about changing a  // objectName. It's safe here
   action->setObjectName(name);



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