Class JRootPane

java.lang.Object
vaadinx.awt.Component
vaadinx.awt.Container
vaadinx.swing.JComponent
vaadinx.swing.JRootPane
All Implemented Interfaces:
ImageObserver, MenuContainer, Serializable, Accessible
public class JRootPane extends JComponent implements Accessible
Emulator for JRootPane — a thin shell over SJRootPane (SD_sjframe): the surrogate carries the Enter- shortcut install and its own "defaultButton" PCE; the emulator keeps its AWT-typed content / layered / glass pane holders and its own listener chain so migrated code registered at the vaadinx.swing.JRootPane layer hears events on its own side (same two-layer convention as SJSlider / SJSpinner / SFrame).

Structural, and the containment is the JDK's

This root pane sits between the window and its content pane, as Swing's does, and holds the JDK's own chain: 
JRootPane
├── glassPane                (index 0, as in the JDK)
└── JLayeredPane
    ├── JMenuBar
    └── contentPane
The menu bar belongs to the layered pane, not to this pane — javax.swing.JRootPane's class doc states it outright, and both of the layered pane's children go into the same FRAME_CONTENT_LAYER, so the layering is not what stacks them. RootLayout stacks them in y, reaching through the layered pane to do it; SB-Emulators spells that as CSS on the surrogate chain. The three panes are built in the constructor through the JDK's own createGlassPane / createLayeredPane / createContentPane hooks, in the JDK's order — which is what makes a migrator's override of any of them actually run (R_no_vaadin_in_api limb 2).

What is not reproduced is the layered pane's z-ordering: layer constants round-trip but reorder nothing, since Vaadin renders in DOM order and JInternalFrame renders as a Dialog overlay instead (D_internal_frames).

See Also:

  • Field Details

  • Constructor Details

    • JRootPane

      public JRootPane()
      Peers on its own SJRootPane. A window's setRootPane hands that same surrogate to the window's surrogate, so both layers share one root pane and the Enter shortcut setDefaultButton installs follows the window through a single listener.

  • Method Details

    • createContentPane

      protected Container createContentPane()
      Factory for the default content pane, called from the constructor. Real Swing returns a JPanel with a BorderLayout; the built-in BorderLayout writes its CSS onto Container.peerContentElement() either way, so a plain Div-backed Container is equivalent here.

    • createLayeredPane

      protected JLayeredPane createLayeredPane()
      Factory for the default layered pane, called from the constructor.

    • createGlassPane

      protected Component createGlassPane()
      Factory for the default glass pane, called from the constructor. Invisible as in the JDK, so a later setVisible(true) is what curtains the window.

    • getContentPane

      public Container getContentPane()

    • setContentPane

      public void setContentPane(Container content)
      The JDK's body: detach the outgoing pane from the layered pane, then add the incoming one there. Children are not migrated — callers that want to keep content must re-add to the new pane.

    • getLayeredPane

      public JLayeredPane getLayeredPane()

    • setLayeredPane

      public void setLayeredPane(JLayeredPane layered)
      Faithfully does not migrate the menu bar or content pane into the new pane — the JDK's setLayeredPane swaps only its own child, leaving them parented to the outgoing pane, which is why nothing but a look-and-feel calls it.

    • getGlassPane

      public Component getGlassPane()

    • setGlassPane

      public void setGlassPane(Component glass)
      Plant glass as this pane's first child — the JDK's index as well as its containment (rootPane.add(glassPane, 0)), so a later getGlassPane().setVisible(true) renders a curtain that blocks mouse input beneath it (D_glasspane_structural/SD_glasspane_structural).

    • getJMenuBar

      public JMenuBar getJMenuBar()
      null until setJMenuBar(JMenuBar) plants one.

    • getMenuBar

      public JMenuBar getMenuBar()
      JDK alias for getJMenuBar(), deprecated there since 1.1.

    • setJMenuBar

      public void setJMenuBar(JMenuBar bar)
      Plant bar in the layered pane at FRAME_CONTENT_LAYER, above the content pane — the JDK's own containment (layeredPane.add(menuBar, FRAME_CONTENT_LAYER)). Pass null to detach. Fires nothing: neither JFrame nor JDialog nor JRootPane fires a bound property for the menu bar (D_window_fanout); JInternalFrame is the sole javax.swing class that does.

    • setMenuBar

      public void setMenuBar(JMenuBar bar)
      JDK alias for setJMenuBar(JMenuBar), deprecated there since 1.1.

    • addImpl

      protected void addImpl(Component comp, Object constraints, int index)
      The JDK's body verbatim: add normally, then re-assert the glass pane at index 0 if it slipped. Deliberately does not redirect into the content pane — rootPane.add(child) adds a direct child of the root pane in Swing too, which is why JRootPane's own class doc tells callers to add to getContentPane() instead. The redirect belongs to JFrame / JDialog / JWindow, which is where rootPaneCheckingEnabled lives; JRootPane has no such flag.
      Overrides:
      addImpl in class Container

    • getDefaultButton

      public JButton getDefaultButton()

    • setDefaultButton

      public void setDefaultButton(JButton button)
      Install button as the root pane's default button — Enter anywhere inside the enclosing window triggers its click. Browser-side shortcut install is delegated to the SJRootPane peer (which owns the ShortcutRegistration and its button-tied lifecycle). The emulator fires its own "defaultButton" PCE on this layer — the surrogate fires its own independently.

    • getUIClassID

      public String getUIClassID()
      Overrides:
      getUIClassID in class JComponent

    • getAccessibleContext

      public AccessibleContext getAccessibleContext()
      Specified by:
      getAccessibleContext in interface Accessible
      Overrides:
      getAccessibleContext in class Component