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.

[MortenMacFly]

At start up, the framework and each plugin should "register" the menu commands/popup/toolbar items it offers with a unique ID.

Exactly what I meant. Just that the menu's ID is automatically given by the wxMenu item, which is unique in itself. So IMHO there is no need to provide more information than the menu.

[dmoore]

At start up, the framework and each plugin should "register" the menu commands/popup/toolbar items it offers with a unique ID.

Exactly what I meant. Just that the menu's ID is automatically given by the wxMenu item, which is unique in itself. So IMHO there is no need to provide more information than the menu.

You need persistent IDs for keybinder (which is why keybinder currently uses the menu label) and to let the user control whether certain items will or will not display. wxIDs like Menu ID's are dynamic, so this is a problem. (Even bigger problem for popup items).

[MortenMacFly]

You need persistent IDs for keybinder (which is why keybinder currently uses the menu label)

The label, maybe in combination with the parent item, is just fine - including for popup menus IMHO. I do it similar in another project of mine.

How would you do persistent ID's otherwise? (Maybe I misunderstood "persistent" - you don't mean globally unique ID's that don't change through sessions, do you?!)

[dmoore]

You need persistent IDs for keybinder (which is why keybinder currently uses the menu label)

The label, maybe in combination with the parent item, is just fine - including for popup menus IMHO. I do it similar in another project of mine.

But it doesn't work for menus that dynamically update their label: e.g. "Find declaration of: 'NULL'"

The simplest thing to do would be to assign a unique XRCID (or equivalently "name" member) to every menu/toolbar/popup item. This would nicely tie in nicely to the wxWidgets event system. This would make it easy to find items in, say, a menu by using wxWindow::FindWindowByName, wxWindow::GetName etc.

EDIT: Turns out this isn't so simple -- I forgot MenuItem's aren't derived from wxWindow...

It might also be possible to have the SDK supply unique names using wxWindow::SetName, but would have to be careful not to break XRC based UI.

[dmoore]

How would you do persistent ID's otherwise? (Maybe I misunderstood "persistent" - you don't mean globally unique ID's that don't change through sessions, do you?!)

So what would be so bad about this? To do this stuff we want to do, we need some mapping between a unique ID (that lets us store persistent information about the menu/popup/toolbar items such as keybindings and hidden state) and their run-time id's. We defacto do this right now using the label, but why not just take it a step further and use a unique ID?

[MortenMacFly]

So what would be so bad about this?

I am not saying its bad, I just want to understand your idea.

So - there are many ways, some are:

• use menu addresses as ID's, not provided by the plugins
• use menu labels (including parent labels) for ID's, not provided by the plugins
• use an ID provided by a plugin (might interfere with another)
• use some kind of global UUID

...for all these cases I am not sure how easy it would be to store e.g. the settings for these ID's so you can manipulate menus across C::B session. The overall goal would be to allow the user to modify the menu items (s)he want to see, any maybe even the order. You brought in dynamic menu labels (like for spell checking) which is something I did not even consider.

[oBFusCATed]

We have lots of them, example: watches, data breakpoints, various find .... of...

[dmoore]

• use an ID provided by a plugin (might interfere with another)

could use the plugin ID as a prefix: e.g. "codesnippets/AddSnippet"

[Alpha]

Just to let people know, I agree that this registering system is better than the current system, however, I do not yet have any very good ideas of how to create it (nor really quite enough willpower .  I am still working on reorganizing the menu using the current system, and will hopefully come up with something a bit more efficient (for use until such a time as someone implements menu registration).

(If anyone here has decided to work on menu registration now, please tell me so I do not waste time with writing code that will immediately become obsolete.)

[oBFusCATed]

(If anyone here has decided to work on menu registration now, please tell me so I do not waste time with writing code that will immediately become obsolete.)

Don't waste time if you don't write a menu registration system. If dmoore hasn't implemented such system until I get some free time, I'll do it, as I have some ideas

[dmoore]

(If anyone here has decided to work on menu registration now, please tell me so I do not waste time with writing code that will immediately become obsolete.)

Don't waste time if you don't write a menu registration system. If dmoore hasn't implemented such system until I get some free time, I'll do it, as I have some ideas

I don't have any immediate plans, but maybe in a few weeks (say 3) if noone else has started I will take a look. I'll be happy to test others code. It will take a bit of planning and is a reasonably big job because of all the plugins that will need to be refactored.