Version: (using KDE Devel) Installed from: Compiled sources OS: Linux Steps to reproduce: - open kate - click terminal button on the bottom - type "exit" (sometimes it doesn't crash the first or second times, but it eventually does)
Created attachment 22407 [details] backtrace
Created attachment 22444 [details] Patch for konsolepart
Ok, the real messup is in konsolepart. This bug should be reassigned there. The problem is, that it's not a good idea to forcibly insert and remove child XMLGUIClient, though I don't have a good understanding, where the problem is. Side-effects other than the crash include that the "Scrollback" menu is shown as "No text", otherwise. On a more general scope, a) I don't quite understand, why clients need to be inserted / removed at all, when the konsole view changes. Can't the same XMLGUIClient be reused? b) I doubt it's a good idea to forcibly insert / remove the client in the hosting application. At least, probably this should not happen *unless* there already is a factory() for the part, i.e. the hosting application has actively merged the part GUI. The part should not try to find a factory by all means. But this is the reason why I'm not re-assigning, yet: The current behavior adds the konsolepart GUI to kate, automatically. This is certainly desirable at least for the konsole context menu. However, I'm not sure, whether we really want all the other menu-clutter that the konsolepart adds. Comments?
Created attachment 22448 [details] Different approach Or, in other words, perhaps this second patch is more desirable (it has it's own ugliness, but removes other ugliness): Here, if there is no factory for creating the context menu, one will be created on the fly. The good thing is that this does not force the hosting application to merge the full GUI just to get the context menu.
Thomas, did you do anything to drag the konsole maintainers attention to this?
> The problem is, that it's not a good idea to forcibly insert > and remove child XMLGUIClient, though I don't have a good > understanding, where the problem is. Each terminal session in the Part has its own client which provides session-specific actions. The only menu needed in the part is the context menu on right-click, as per KDE 3. In KDE 3 the context menu for the part was constructed manually in code, I wanted to avoid this if possible and use XMLGUI instead. There isn't supposed to be any integration of Konsole's main menu and the hosting application's menu. > However, I'm not sure, whether we really want > all the other menu-clutter that the konsolepart adds I'm pretty sure you don't want that. Any menu items which are usually on the main menu in the main Konsole application which are needed from the part should ideally be put into the context menu. I cannot test the attached patch as my laptop is without a hard drive at the moment so I am working off a live CD. The second one looks correct.
Ok, should I apply it then, or would you rather take care of things yourself from here on (get well, soon, poor laptop)?
> Ok, should I apply it then, Yes please.
SVN commit 747059 by tfry: Create a KXMLGUIFactory for the context menu on the fly, if needed, instead of forcibly merging with the hosts GUI. BUG: 153646 M +2 -22 Part.cpp M +11 -0 SessionController.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=747059