This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The problem with current menu & toolbar impelementation is it doesn't fit to the new winsys design. It doesn't separate its configuration from GUI components, those are sticked together in current impl. Especially it seems it is problematic, when requested those structures first time to provide its GUI representation, it starts to provide the loading data from files internally, blocking the requested thread. This kind of behaviour is unwanted. It would seems it is necessary to revise it and possibly to devide, so is it possible better internally to manipulate with.
*** Issue 37263 has been marked as a duplicate of this issue. ***
I've chenged to DEFECT, just for don't forget (issue 37263) solve it.
re-evaluate please ...
Changing back to task, this issue is really a design request, not a bug. The problem that we have bugs depending on this issue IMO doesn't change nature of this issue, it's still a task, and btw not cheap.
Of potential interest: contrib/menus What it is: A system for building menus (which actually work correctly, even with the screen menu bar on mac) and a legacy bridge to the existing mess. The menus are composed from a TreeModel. When something changes in the model, a menu simply sets a "dirty" flag that it should ask to be re-composed before it is shown. Works fine everywhere (except the bridge has the same problems it currently has because it's really using all the old code). It wouldn't be hard to build a toolbar implementation on a similar model. The idea is that legacy actions can keep working through the bridge, but we could create an entirely new (mostly declarative) infrastructure for declaring menu items, and we just need a TreeModel that composes the legacy bridge's contents and whatever the new implementation is. Complete flexibility. Also possibly of interest for inspiration - performance/actionsframework (this one *does* contain a toolbars implementation). It's mainly a proof of concept that you can use a timer and polling, along with a dirty flag, to update actions and get comparable performance to actions actually updating themselves one-by-one in response to events - so you get automatic thread safety and you don't have NetBeans spending lots of time to figure out that nothing has changed, once for every toolbar button. One thing to remember in any implementation is to special-case startup rather than handling it the same way as any set of events that affect toolbars/menus/whatever.
I added core-promoe status, to finally address this.
Prioritizing.
Unfortunately not done in 4.1, I don't know when this could be adresssed, no plans to do it now.
changing summary, toolbars redesign is tracked here: http://www.netbeans.org/issues/show_bug.cgi?id=59242
No resources and plans to work on this, leaving up to community, work and patches welcomed...