Working draft, part of PlatformPoolOfRcpTopics planning, see also previous discussion for NB 6.7.


Use Cases

  1. hide unwanted menu items from platform module(s)
  2. be able to see hidden items and show them again
  3. reorder menu / toolbar
  4. rename windows / actions / ..., change icons
  5. reorder / preview window layout
  6. true control over main window title


  • locate package for bundle or resource
  • locate layer path for layer item
  • locate originating module (to potentially disable it instead of hiding items)
  • track the above-mentioned info across shadow files
  • UI for editing branding


For preceeding discussion see #Possible Solutions below.

Depends on changes in FixedLayerView69, however if layer editor is implemented as proposed, branding editors are convenient extensions of the layer editor, not a necessary part of it. Still, at least visual window layout editor is highly desirable, other editors may be added later.

Window Layout Editor

Proposed solution is to implement it as a tab in layer editor. Based on visual library it displays rectangle denoting app window divided into modes and with windows assigned to them (shown as labels in mode rectangles):

|<explorer mode>  |<editor mode>                |
|Projects         |                             |
|Files            |                             |
|Favorites        |                             |
+-----------------+                             |
|<navigator mode> |                             |
|Navigator        +-----------------------------+
|                 |<output mode>                |
|                 |Output                       |


  • the easiest and simplest solution is letting user run their application, open their windows, rearrange them to desired modes and have a button to save and copy the customized layout into their module layer. There might be some plugin(s) on plugin portal that does something similar. However not all windows might be available when the application is running and the generated layout would use non-descriptive, anonymous names for newly created screen areas (modes).
  • The first iteration of full-blown visual editor doesn't have to include drag-and-drop or 'interactive' window layout schema. The editor can use properties window/context menu/dialogs to define which window and mode properties.
  • The next release may add drag-and-drop of windows from a palette of all windows defined in the application, mouse-resizing of window areas etc.
  • Some changes in window layout would have to be stored as branding of platform module(s), e.g. when window defined in platform module is moved to a different mode. Or the module introducing layout changes must declare dependencies on other platform module(s) to ensure that its XML layer modifications are loaded in correct order.

Possible Solutions

More or less WYSIWYG editor of main menu, toolbars, window layout and window modes of RCP app, since this is what must be branded in let's say 95% of apps. Proposed editor would show simplified view of the items (e.g. labeled rectangles instead of windows, etc.). It differs from This layer in context node in several ways:

  • It is invoked on RCP app project (suite) to allow for direct branding editing (currently must be hacked around by editing a module project and copy resulting layer/bundles into branding)
    • as an implementation matter, branding ought to be moved into a dedicated branding module, as the Maven "suite" archetype already does
  • Probably deserves full editor window instead of nodes in Projects; especially for window layout and modes is (simplified) WYSIWYG editing much more useful than layer nodes
  • could also make getting rid of this layer in context editor altogether possible, see FixedLayerView69 for details
  • it would probably not be necessary to listen on all 600+ layer file changes, a Refresh button would do; this would lead to better performance and faster development time

Alternative approach is to enhance current this layer in context node to be able to edit branding. Pros:

  • users are used to it
  • most of the code for UI already exists
  • shows "live" data (i.e. listens to changes)


  • deep node hierarchy in side window is not convenient for extensive editing and WYSIWYG editing cannot be easily added
  • shows branding items together with other service provider registrations, they are largely unrelated; again see also FixedLayerView69
  • shows "live" data (performance)
  • edit operations currently implemented using MultiFileSystem and therefore have a number of surprising and sometimes undesirable effects
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo