Revision as of 12:02, 14 December 2009 by Rmichalsky (Talk | contribs)

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                       |

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