D17308: Make CTags/Projects context menu more accessible
René J.V. Bertin
noreply at phabricator.kde.org
Mon Jan 14 11:02:50 GMT 2019
rjvbb added a comment.
Should I check if current master works as I intended, WITHOUT your patch, because it does not apply to current master.
Personally I see no reason to "unroll" the CTags submenu, nor to remove the dynamic menu items, and I see reason not to change these aspects.
So -2 (2 * -1) from me for the original idea.
I like to see what the search is going to be for before starting it. That search might open (or change) the toolview and it will probably open a document. Both are effects that are more disruptive to correct than closing the submenu.
Remember that this plugin can also be used in KDevelop where its menu will appear in menubar and context menus that are considerably more cluttered already than the one in the screenshot you're showing me. In addition, the CTags plugin has a bit of an "if all else fails" nature in KDevelop, which already has much better integrated similar functionality for a few supported languages. IOW, the CTags functionality should really be in a submenu there.
In short, to come back to my -2: change what you want but try to keep things as unchanged as possible when the plugin is loaded in KDevelop. This will also allow the plugin to integrate properly with Kate's project manager plugin (which will probably never be supported in KDevelop).
The host application can be detected in several ways, the most reliable is in the ctor of the KTextEditor::Plugin child class. From my zealsearch plugin:
// parent->metaObject()->className() == "KatePluginManager" in kate
// parent->metaObject()->className() == "KDevelop::Core" in KDevelop
To: gregormi, #kate, sars
Cc: rjvbb, dhaumann, sars, ngraham, kwrite-devel, hase, michaelh, demsking, cullmann
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KWrite-Devel