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.
Ability to brand arbitrary XML layers in the app, by browsing the composite system file system of the application (meaning all XML layers in the base platform, plus all XML layers defined by modules in the suite), and performing operations on that SFS indicating the desired state of the app. (The diff would be computed automatically and stored as a branding layer for you, so you do not need to understand the branding syntax). Examples of possible operations include the following (but more is possible): 1. Deleting unwanted menu items (or whole menus, toolbar items, ad nauseam). 2. Changing the order of menu items. 3. Changing display labels of menus, actions, etc. (Would mean finding the bundle that actually defines it, and automatically branding that bundle.)
Sketch of UI: Demo Suite Modules Demo Module #1 Demo Module #2 Branding Resource Overrides Core - UI org.netbeans.core.ui.resources layer.xml Menu File org-openide-actions-PrintSetup.instance_hidden Application Layers Menu File .... [no PrintSetup] .... .... *Application Layers* presents a view of the system (configuration) filesystem of the application. This is composed conceptually by merging all the XML layers of modules in the target platform with all the XML layers of modules in this suite and all the branded XML layers in *Resource Overrides*. The developer should be able to interactively modify this tree to represent what he wants the result to look like; behind the scenes the IDE should actually be creating entries in branding layers which would create that effect. For example, selecting an unwanted menu item beneath the Menu subnode and pressing *Delete* should result in a *_hidden file being quietly created in some XML layer beneath *Resource Overrides*, thus branding the module which originally defined that menu item. Details of permitted actions (e.g. changing display labels or reordering items) TBD.
*** Issue 71439 has been marked as a duplicate of this issue. ***
Well as described in bug 71439 I have (nearly) successfully used existing support to overwrite default layers - e.g. just create a module, go to its layer, view it is context and start to modify it. For example edit and Windows2/Modes/*.wstcref files etc. This all works fine. There is just one problem and it is the set of missing runtime dependencies - e.g. every time one overwrites a file, its module shall get runtime dependency on the original provider of the file.
Issue #141925 would make it much easier to implement.
That would be a way how to implement visual editing of NB platform app UI (http://wiki.netbeans.org/APISupportInNetBeans7.0), however this seems to get postponed to further release. I'd like the UI to be more WYSIWYG than simple tree though, even at the price of slower implementation.