Core Swing components (1)

In Chapter 3rd, we briefly introduce the Model-View-Controller (MVC) mode used by JFC/Swing engineering components. In this chapter, we will begin to explore the key aspects of using many available components.

All Swing components start with the JComponent class. Although some parts of the Swing library do not take the JComponent class as the root, all components share the JComponent class as the common parent class at some level of its inheritance. The JComponent class defines common behaviors and attributes. In this chapter, we will learn about some common functions, such as component rendering, custom definition, tooltip, and change size.

With the attention of specific JComponent child classes, we will have a special understanding of JLabel, JButton, and JPanel, three more widely used Swing component classes. To display images in components, we need to understand the Icon interface and support for the ImageIcon and GrayFilter classes when using pre-defined images. In addition, we will understand the javasactbutton class, which is the parent class of the JButton class. The data model shared by all the child classes of AbstractButton is the ButtonModel interface. We will discuss this interface and its specific implementation, DefaultButtonModel.

4.1 JComponent class

The JComponent class is the abstract base class inherited by all Swing components. The JComponent class has 42 Derived subclasses, each of which inherits the JComponent function. Figure 4-1 shows the inheritance hierarchy.

Although the JComponent class is the common base class of all Swing components, many classes in the Swing project library are not derived from the JComponent class. This includes all high-level window objects, such as JFrame, JApplet, and JInternalFrame, all MVC-related classes, and event processing-related interfaces and classes. All these classes will be discussed in the following sections.

Although all Swing components extend JComponent, The JComponent class extends the Container class of AWT. Correspondingly, it extends the Component class of AWT. This means that many JComponent aspects are shared by the Component of AWT and the Container class.

4.1.1 component partitioning

The JComponent class defines many AWT component surfaces that exceed the functions of the original AWT component set. This includes custom painting behavior and different methods of custom display settings, such as color, Font, and other client settings.

Draw a JComponent object

Because Swing's JComponent class is extended by the iner class, it follows the basic AWT drawing model: All the painting is done through the paint () method, while repaint () method is used to trigger an update. However, the completion of many tasks is different. The JComponent class optimizes many aspects of rendering to improve performance and scalability. In addition, the RepaintManager class can be used to customize the painting behavior.

To improve the rendering performance and scalability, JComponent divides the painting operation into three tasks. The public void paint (Graphics g) method is divided into three independent protected method calls. The Graphics parameters are transmitted through the original paint () call, which are paintComponent (g), paintBorder (g), and paintChildren (g) in sequence. The component itself is first drawn through paintComponent (g. If we want to customize the drawing of the Swing component, We can override the paintComponent () method instead of the painting () method. Unless we want to completely replace all plotting, we need to first call super. paintComponent (), as shown below, to obtain the default paintComponent () behavior.

public class MyComponent extends JPanel {  protected void paintComponent(Graphics g) {    super.paintComponent(g);    // Customize after calling super.paintComponent(g)  }  ...}

PaintBorder () and paintChildren () methods cannot be rewritten. The paintBorder () method draws the border around the component. Chapter 7th gives a more complete description of its concept. If a component exists in the Swing container object, the paintChildren () method draws the component.

The JComponent class provides three additional drawing attributes: opaque, optimizedDrawingEnabled, and doubleBuffered. Its functions are as follows:

• Optacity: the opaque attribute of JComponent defines whether a component is transparent. When transparent, the JComponent container must draw a background after the component. To improve performance, we can retain the opacity of JComponent and make JComponent draw its background, instead of relying on containers to draw the overwritten background.
• Optimization: whether child elements adjacent to the optimizedDrawingEanbled attribute can overlap. If child elements cannot overlap, the re-painting time can be greatly reduced. By default, optimized rendering is allowed for most Swing components except jshorttoppane, JLayeredPane, and JViewport.
• Double buffering: by default, all Swing components cache their painting operations to the buffer shared by a complete container hierarchy; that is, all components in a form. This greatly improves the rendering performance, because when dual buffering is allowed (through the doubleBuffered attribute), only one screen updates the painting.

The public void revalidate () method of JComponent also supports plotting. When this method is called, the advanced container of the component verifies itself. This is different from AWT's direct call to the revalidate () method of the advanced component.

The RepaintManager class is the final aspect of the Swing component painting enhancement.

RepaintManager class

The RepaintManager class is responsible for ensuring the efficiency of repainting requests on the currently displayed Swing components, and only updating the minimum "dirty" Area of the screen when an area is invalid.

Although it cannot be customized, RepaintManager is public and provides a static installation routine to use the custom manager: public static void setCurrentManager (RepaintManager manager ). To obtain the current manager, you only need to call the public static void currentmanager (JComponent) method. The parameter is usually null unless we have customized the manager to provide component-level support. Once we have a manager, one thing we can do is to get the screen buffer as an image. Because the buffer zone is the content actually displayed on the screen, this enables us to efficiently copy the screen inside the form.

Component comp = ... RepaintManager manager = RepaintManager.currentManager(null);Image htmlImage = manager.getOffscreenBuffer(comp, comp.getWidth(),  comp.getHeight());// orImage volatileImage = manager.getVolatileOffscreenBuffer(comp, comp.getWidth(),  comp.getHeight());

Table 4-1 lists the two attributes of RepaintManager. This allows us to disable double buffering for all painting operations of a component (hierarchy) and set the maximum double buffering size. The default size is the screen size of end users.

RepaintManager attributes

Attribute name	Data Type	Accessibility
DoubleBufferingEnabled	Boolean	Read/write
DoubleBufferMaximumSize	Dimension	Read/write

Although few implementations are available, providing our own RepaintManager subclass does allow us to customize the rendering mechanism for dirty areas of the screen, or the minimum trace when the painting is complete. You can override one of the following four methods to allow custom mechanisms:

public synchronized void addDirtyRegion(JComponent component, int x, int y,  int width, int height)public Rectangle getDirtyRegion(JComponent component)public void markCompletelyClean(JComponent component)public void markCompletelyDirty(JComponent component)

UIDefaults class

The UIDefaults class indicates the query table containing display settings installed for the current view, such as the font used in the JList and the color or icon displayed in the JTree section. The use of UIDefaults will be discussed in detail in chapter 20th about the pluggable Java sensory architecture. Here, we will briefly introduce the UIDefaults table.

When we create a component, the component automatically requests UIManager to find the current settings used by the component in the UIDefaults table. Most color, font-related component settings, and other settings that are irrelevant to the color and font are configurable. If you do not like a specific setting, you can simply update the UIDefaults to query the corresponding items in the table.

First, we need to know the name of the UIDefaults settings we want to modify. We can find these setting names in Appendix A of this book, which contains A complete list of all known settings with pre-defined perception in J2SE 5.0. (The release version varies slightly .) In addition, each component is described as a table containing the UIResource-related attribute elements. (To find specific components in this book, check the content table or index .)

Once we know the set name, we can use the public static void put (Object key, Object value) method of UImanager to store a new setting, where key is the key value string. For example, the following code changes the background color of the newly created button to black and the foreground color to Red:

UIManager.put("Button.background", Color.BLACK);UIManager.put("