Plugin causing duplicate entries in the document context menu

René J.V. Bertin rjvbertin at gmail.com
Mon Nov 12 13:22:04 GMT 2018


On Monday November 12 2018 12:58:18 Kevin Funk wrote:

> > Context menu generation is a little complicated so I haven't yet found a
> > spot to put my finger on. It seems to have to do with the fact the plugin
> > uses KXMLGui to manage it's menus(?).
> 
> Nope.

Are you sure? The issue disappears when I remove both the `actionCollection()->addAction(QLatin1String("popup_ctags"), m_menu);` expression from the KateCTagsView ctor AND the corresponding entry from the kxmlui ui.rc file.

Is it possible to let a plugin use KDevelop::ContextMenuExtension only when loaded into KDevelop and/or load a different ui.rc file depending on the application loading the plugin? If not I'm guessing that there's no good way to support this plugin in both Kate and KDevelop without getting rid of the context menu altogether (which would be a pity).

I guess ContextMenuExtension should be moved, or a skeleton should be implemented in KTextEditor (not unlike KTextEditorIntegration)?

> Your screenshot indicates that e.g. the patchreview plugin is loaded twice(?). 
> The "Review Patch" string is found in patchreview.cpp.

I think the observation above pleads against that hypothesis, as does the fact that it would mean reload count increases each time you switch to a new document.

I rather think that there's a caching issue where the context menu (which is populated dynamically IIRC) ends up appending actions that are already present because the ctags submenu appears at the top instead of being appended below the bookmarks submenu. Something like "ok to add this item if it is not the last added item" instead of "ok to add if this item is not already the last (lowest) in the menu".
FWIW, the CTags submenu does appear below the bookmarks submenu in one situation: when you load the CTags plugin after having started KDevelop without it being loaded - and only in the document that is active when you load the plugin.

> Or something in PluginController::queryPluginsForContextMenuExtensions is 
> wrong (or patched wrongly...).

Until now I have only been patching the ctags plugin itself.

The "good" news here is that the main kate-ctags author is planning to abandon the whole thing in favour of its equivalent in  Kate's project manager plugin. I'm not going to consider bringing that one over to KDevelop, so one way out of this catch-22 would be to add a special KDevelop version of the CTags plugin (standalone or not) and optionally ensure that the 2 plugins can use the same database.

R.


More information about the KDevelop-devel mailing list