JMRI: Use of Swing

We use Java Swing for our GUI development. It's a lot more powerful than the original AWT, and the price is right. In particular, we try to use the "Bean format" of setting and getting members, call-backs to notify of changes, etc, to make it easier to build applications from JMRI components.

We have been evolving a particular pattern for using Swing, described here. The JMRI codebase contains several generations of implementations, so not all of it looks like this, but we're moving classes in this direction as time allows.

The basic structure is to implement graphical tools as JmriPanel objects. These are JPanels with enough extra structure that the JMRI applications can directly work them. For example, a JmriPanel subclass can be instantiated and placed in a properly laid out window by creating a JmriNamedPanel action with just the name of the JmriPanel class, which in turn can be done with various automated tools.

This pattern lets us write a tool panel just once, and then use it in lots of various places, embedded into windows in several ways. It also greatly reduces the number of classes that need to be loaded at startup time, because there are not separate *Action and *Frame classes, and JmriPanel subclasses don't have to be loaded just because they are listed in a menu.

The jmri.util.swing package contains the suppoer code.

Life Cycle of a JmriPanel

First the ctor runs, then initComponents. That second part should be the place for connections to other components, as all lower level objects have been created. (subclasses for particular systems might have e.g. more initComponents methods, called later)

Dispose is called at the end. (Note that JPanels don't have a dispose(), that's normally only part of JFrames, but we provide it here for cleanup)

JmriPanels are best created by name with JmriNamedPaneAction, which has the advantage of greatly reducing the number of classes that need to be loaded to populate a menu.

If it can't be done by name, then JmriAbstractAction is the base.

Use of WindowInterface to create subwindows, so as to put them in the right place.

(See the JavaDocs in that package, which are pretty good)

JmriJFrame is in the wrong place for now.

Older classes, some still to be moved to jmri.util.swing, some are 1.1.8 adapters that should just go away.

AbstractFrameAction
BusyGlassPane
FileChooserFilter
FontUtil
JTableUtil
JmriInsets
JmriJFrame
JmriJFrameAction
JmriSpinner
MouseInputAdapterInstaller
ResizableImagePanel
WindowMenu