Tidy main context menu

[Alpha]

The main context menu (from right-clicking in the editor) is huge.  I plan to try reorganizing it to be more manageable/efficient.

If people could post which menu entries they use the most, and which (if any) they rarely/never use, it would be helpful to my reorganization.

[ollydbg]

I mostly use:
Context menu:
Edit->Copy
Edit->Paste
Find declaration of xxx
Find implementation of xxx
Find occurrence of xxx

I nearly do not use other items.

"Run to cursor" should not exist when the debugger is not running, right?

[p2rkw]

I don't use: toggle breakpoint, swap header/source, open containing folder, Edit, Folding, split view, configure editor, remove from project, show file in project tree.
Most of context menu items are related to current file. My suggestion is to move these items ( if they aren't already there ) to tabs context menu.

[ollydbg]

I don't use: toggle breakpoint, swap header/source, open containing folder, Edit, Folding, split view, configure editor, remove from project, show file in project tree.
Most of context menu items are related to current file. My suggestion is to move these items ( if they aren't already there ) to tabs context menu.

Agree.
Some of the menu item like "swap header/source, open containing folder" were also shown in the editor tab context menu, I use them sometimes, but I think they should only be in tab context menu.

[oBFusCATed]

The last and only try I had at discussing this failed miserably and the poll was an internal one.
Everybody uses a subset of this menu and doesn't like items removed from it.

This is what I've written back then:

I've some targets, which I think should be removed:
1. Configure editor (never used this one and never would)
2. Remove file from project
3. Show file in project tree
4. Swap header/source
5. Open containing folder
6. Properties

(2-6 can be found in the context menu for the notebook).
I think this group of items should be removed 100%.

For the next group I have some doubts (50:50% here):
1. Split view (I think this should stay, because many people can't find this feature)
2. Bookmarks
3. Folding

The answer to this post was pretty negative.
So, I think the best option is to provide an UI for hiding certain item. By name or by regexpr.
So the users sees an menu item he/she doesn't like. Goes to the settings and hides it.
All other option will make us suffer and we would have to answer questions like:
"Why have you removed XXX, I use it and like it and I want it back, else I switch IDEs?".

"Run to cursor" should not exist when the debugger is not running, right?

Why not? Have you tried it to see what it does in this situation

[Alpha]

"Why have you removed XXX, I use it and like it and I want it back, else I switch IDEs?".

I am not planning to remove any functionality, just reorganize to make the most used items easily accessible, and hopefully decrease the size of the menu.

So, I think the best option is to provide an UI for hiding certain item. By name or by regexpr.

This is also something I will be trying to do.

[dmoore]

A long time ago, mandrav, the founder of the project had started work on a registry for toolbar/menu/popup menu items. This would make it much easier to offer a UI that would give the user more control over what shows up and in what order. Apparently he lost the work, but the idea is a good one. A lot of the clutter that plugins create could then be turned off by default.

[Alpha]

That sounds like an interesting idea, but I am not certain I understand exactly what you are describing.  Do you have more details?

[Alpha]

Are there any objections to hiding CC's "Find ... of: ..." entries when (1) the current file is not C/C++, and (2) the item is in a string/comment?

[MortenMacFly]

First of all, these items I use regularly:
- Find declaration/implementation/(...) - all of them
- Insert class methods with...
- Swap header/source
- Folding: fold/unfold all
- all of aligner
- Permanently highlight...
- Add ToDo item...
- Show file in project tree
- Spelling suggestions -> should be way more at the top, btw!

The Find... options could be grouped which would shrink the menu a lot. But I honestly think the best way would indeed be a registry. The menu items used here are really user specific, so everything you think is good, won't be for others (remember the simple switch header/source discussion). In the end the core knows all it needs to know for a registry, as plugins have register their menus.

Are there any objections to hiding CC's "Find ... of: ..." entries when (1) the current file is not C/C++, and (2) the item is in a string/comment?

This is such a case: Think about that you don't know exactly, what items are C/C++ - its a user option.

[Alpha]

Menu registry would be a useful, however, I currently am unsure of how to implement it.  Until a design is figured out (by me, or anyone with ideas about it), I will see what I can to with organizing the existing structure.

[MortenMacFly]

Menu registry would be a useful, however, I currently am unsure of how to implement it.

I think most of the bits and pieces are there already. Basically the interface would change, so that plugins are not offered a menu which they can access themselves, but offer a menu they would like to plugin to and the code (SDK) decides where and if to plug.

So the interface functions are there, just the "direction" needs to change and the handler in the SDK that sorts the menus.

[ollydbg]

"Run to cursor" should not exist when the debugger is not running, right?

Why not? Have you tried it to see what it does in this situation

I just tried, when click on this menu item, it will start the debugging session, but sometimes it does not stop on the current cursor.( in this case,  I have the option "Do not run the debugee" option checked, then the debugger just halt when started) If this option does not checked, but have some breakpoints setting before the cursor, the debugger will stop at the breakpoint.
I realize that it's the normal behavior "Run to cursor" should do.

Thanks.

[oBFusCATed]

I realize that it's the normal behavior "Run to cursor" should do.

Yes

[dmoore]

Menu registry would be a useful, however, I currently am unsure of how to implement it.

I think most of the bits and pieces are there already. Basically the interface would change, so that plugins are not offered a menu which they can access themselves, but offer a menu they would like to plugin to and the code (SDK) decides where and if to plug.

So the interface functions are there, just the "direction" needs to change and the handler in the SDK that sorts the menus.

Just my 2c:

At start up, the framework and each plugin should "register" the menu commands/popup/toolbar items it offers with a unique ID. That ID could then be used to control whether the item appears, key bindings (cannot current assign keybindings to pop up or toolbar items or menu items whose labels change) and with a lot more work where items appear in menus (I don't think that last one is really necessary, so might be nice).

I am agnostic on the implementation details, but want to keep things simple for plugin authors and don't want to impact runtime performance with lots of checks before opening menus.