Bug 65355/60500
Sascha Cunz
mail at SaCu.DE
Mon Nov 3 10:12:03 UTC 2003
Hi Jens, hi all,
i figured out, why trying to reproduce bug 65355 results in a backtrace like
in bug 60500.
Could you try to confirm that it is gone with current cvs?
In fact, it was a problem with the context menu of the editor part.
PartController creates a KPopupMenu from the XML-GUI. This one was staticly
stored in PartController::contextPopupMenu(). This KPopupMenu seems to be
owned by the XML-GUI.
This menu gets propagated into each editor on opening. At this point,
EditorProxy connects to the menu's aboutToShow.
When the Popup is now about to show, EditorProxy cleans it completely. Then it
asks all around KDevelop to fill the menu. ( There was a bug in this
cleaning, i fixed it: now the menuitems contained in kdevelopui.rc at
"rb_popup" are also shown in the editor's context menu )
After a manual change of the XML-GUI via KEditToolBar-Dialog, the KPopupMenu
stored in the editors is invalid. So opening the next file causes a try to
connect a slot to a deleted object.
I changed PartController::contextPopupMenu, so that it does not cache the
pointer from XML-GUI anymore. This makes opening new files work again.
Now another bug came into front: If one chages a toolbar, the KPopupMenus
"installed" into existing editor parts get invalid. I added code to reinstall
them after the toolbar has been changed.
Here it seems to work now.
Cheers
Sascha
P.S.: All this context-menu stuff is a big big mess, it should be cleaned as
soon as the freeze is gone...
More information about the KDevelop-devel
mailing list