General

The snap-gui module has a dependeny to snap-ceres-ui but no dependency to snap-visat-rcp by intention. The migration to NB consists primarily in moving every component from snap-visat-rcp to snap-gui so that we can entirely get of snap-visat-rcp and reuse only the parts of snap-ui that have no dependencies to JIDE. 

Module Package Structure

The module snap-gui contains the package org.esa.snap.gui which currently has the following sub-structure and is TBC:

• util - Public package containing common NB utilities. Note: none of the classes contained in here shall have dependencies to any other package in this module, because we may wish to put util into a separate module later.
• actions - Public package containing all categorised SNAP top-level actions  (${Name}Action extends AbstractAction and the like)..
  • file
  • edit
  • view
  • interactors 
  • tools
  • window
  • help
• windows - Public package containing all (categorised?) SNAP top-level tool-windows (${Name}TopComponent extends TopComponent and the like).
• nodes - Public package containing the NB node representation, org.openide.nodes.Node, of the BEAM product model, org.esa.beam.framework.datamodel.Product.
• all others - Private packages containing mainly implementation code for the actions and windows contained in the actions and windows packages. TBC: put all others into a package impl. 

Review Heritage Code

While migrating component-wise, we will carefully review every piece of code and make it NB-ready. 

• Mandatory: org.esa.snap.gui.SnapApp is the counterpart for VisatApp. Only move stuff from VisatApp to SnapApp if there is no better solution. Keep number of SnapApp methods to a minimum. But actually try to avoid it's use! This is because VisatApp is monster which makes your components dependent of a lot of things that it should not depend on. Try to move code into dedicated actions. NB provides a number of techniques and utilities supporting development of loosely coupled components, e.g. Lookup, Node, Utilities.actionsGlobalContext().
• Desired: Fix any existing TODO and try to avoid any TODOs in new code.
• Desired: Get rid of deprecated API usages and don't use any deprecated API classes in new code. 
• Nice to have: Try to use @Message annotations to make the GUI I18N-ready.

Tips & Tricks

• You can use org.openide.util.WeakListeners in order to create event listeners that will be removed is the source isn't being used anymore. This minimses the chance of memory leaks (see book NB for Beginners) in case you cannot remove the registered listener. Typical use case: register LookupListener in the constructor of a ContextAware action.

• If you experience that the EDT is blocked shortly after you haven opened the first dialog, or at least shortly after application startup, then you should add -Dsun.awt.nopixfmt=true as VM option to the run configuration.
  The blocking is caused by a known bug in the JDK. Related Bug entries are:

  • [JDK-8019378] Win32GraphicsDevice.isPixFmtSupported[native]() extremely slow

  • [JDK-6477756] GraphicsDevice.getConfigurations() is slow taking 3 or more seconds

  • NetBeans Report #199452

Preferences

Don't use PropertyMap anymore, always use java.util.Preferences instead (SnapApp.getPreferences()), for compatibility during migration use org.esa.snap.gui.compat.CompatiblePropertyMap.

Image Resources

Common image resources go to org.esa.snap.gui.icons and org.esa.snap.gui.cursors. Only copy image resources that are really required for the curret component being migrated so that we can get rid of unused resources.

Replace occurences of org.esa.beam.framework.ui.UIUtils.loadImageIcon(path) by org.openide.util.ImageUtilities.loadImageIcon(path, false) because NB's ImageUtilities takes care of the dark LAF.

TBC: Make use of Tango icons whenever possible:

• Replace help icon (Help24.gif) 
• Replace list add/remove (Plus24.gif/Minus24.gif)

TODO: we use the filter icon (Filter24.gif) when we want to select a band subset. That is confusing, better to use another icon in a consistent manner.