LAF concept (and implementations) is at the heart of the swing MVC. It is beneath just about every JComponent and UI delegate class. I think the concept of swing component’s painting and realization are relevant, if not a cornerstone of LAF implementation. UI delegates are instantiated when JComponent is instantiated, according to my debugging. When a component is “realized”, i believe its corresponding UI delegate “enters” a new state as it is painted on screen and can take user input.
“lightweight” component is one that reuses the native window of its closest heavyweight ancestor.
I think that ancestor is usually a jframe instance
a Swing object does not rely on an associated peer object. This article also covers event queue.
As an application developer, you should think of a component’s view/controller responsibilities as being handled by JButton, JTree,.. The component class then delegates the look-and-feel-specific aspects
of those responsibilities to the UI object of the look-and-feel.
Pluggable look-and-feel means the portion of a component’s implementation that deals with the presentation (the look) and event-handling (the feel) is delegated to a separate UI object of the look-and-feel,
com.sun.java.swing.plaf.windows.WindowsScrollBarUI is a concrete class for such an UI object
The UIManager is the API through which components and programs access look-and-feel information (they should rarely, if ever, talk directly to a LookAndFeel *instance*). UIManager is responsible for keeping
track of which LookAndFeel classes are available, which are installed…