Tidy main context menu

[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.