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