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 Module #1
Demo Module #2
Core - UI
.... [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.