Class SJToolBar

java.lang.Object
com.vaadin.flow.component.Component
com.vaadin.flow.component.HtmlComponent
com.vaadin.flow.component.HtmlContainer
com.vaadin.flow.component.html.Div
com.vaadin.swingbridge.surrogates.SJToolBar
All Implemented Interfaces:
com.vaadin.flow.component.AttachNotifier, com.vaadin.flow.component.ClickNotifier<com.vaadin.flow.component.html.Div>, com.vaadin.flow.component.DetachNotifier, com.vaadin.flow.component.HasComponents, com.vaadin.flow.component.HasComponentsOfType<com.vaadin.flow.component.Component>, com.vaadin.flow.component.HasElement, com.vaadin.flow.component.HasEnabled, com.vaadin.flow.component.HasOrderedComponents, com.vaadin.flow.component.HasSize, com.vaadin.flow.component.HasStyle, com.vaadin.flow.component.HasText, ComponentMixin, ContainerMixin, JComponentMixin, Serializable
public class SJToolBar extends com.vaadin.flow.component.html.Div implements JComponentMixin
Surrogate for JToolBar (SD_sjtoolbar). Action-button row on top of Vaadin Div — same peer SJPanel / SJRootPane use. The toolbar is a free-standing flex container, not a Vaadin HorizontalLayout: the orientation flip (HORIZONTAL ↔ VERTICAL) is symmetric on a plain Div (just a CSS flex-direction toggle), and using HorizontalLayout would force a "horizontal layout that's actually rendering vertically" misnomer the moment a user calls setOrientation(VERTICAL).

Pinned flex CSS

The ctor writes the toolbar's flex CSS directly on the host element: display:inline-flex; align-items:center; gap:var(--vaadin-gap-xs); flex-direction:row|column per orientation. We do not go through the inherited ContainerMixin.setLayout(LayoutManager) CSS dispatch — that's parameterised on JDK FlowLayout / BorderLayout / BoxLayout / GridBagLayout instances and the toolbar wants none of those.

setLayout(LayoutManager) is overridden to drop-and-WARN per R_vaadin_first (we hard-pin flex flow per orientation). Migrators calling toolbar.setLayout(new BorderLayout()) would otherwise have the Border-grid CSS clobber the toolbar's flex CSS — a silent visual regression. Pinning is the safer default; if a real migration target needs custom toolbar layouts we lift the restriction then.

Orientation flip (HORIZONTAL ↔ VERTICAL)

Field source-of-truth + CSS write on every change. setOrientation(int) validates per R_match_swing_errors (IllegalArgumentException matches JDK) and fires "orientation" PCE on actual change.

addSeparator — inline perpendicular thin Div

The toolbar owns its separators inline rather than reaching for the SJSeparator surrogate (SD_sjtoolbar): the 1px-stretch trick is a one-liner and keeps the child a plain toolbar-managed <div>. addSeparator() builds a <div> sized to 1px on the toolbar's cross axis with align-self:stretch and adds it — the same visual shape SJSeparator produces as a standalone flex child. The one-arg form addSeparator(java.awt.Dimension) accepts the dimension and drops it per R_layouts_close_enough — JDK uses the size as a spacing hint; we always paint a thin bar.

setMargin(Insets) → CSS padding

Maps Insets(t,l,b,r) to padding: t r b l on the host element (the CSS shorthand order). getMargin() reads the computed padding-top/right/bottom/left back; null margin removes the property entirely (matches JDK's setMargin(null) semantics of "use L&F default", which here means "no padding").

What lives on the emulator only (asymmetric R_swing_is_truth shadow)

floatable, rollover, and borderPainted have no Vaadin counterpart — no detachable toolbars in a browser, no Vaadin rollover toggle, no painted-border flag distinct from CSS border. R_vaadin_first says drop them on the surrogate side: the methods are not declared here at all. Round-trip lives on the emulator (:emulators.JToolBar's own field shadows, per R_swing_is_truth — same shape SD_sjbutton takes for state-conditional icons and SD_toggle_checkbox_first_cut takes for borderPaintedFlat). Pure-surrogate Vaadin-shape users don't reach for these.
See Also:

  • Constructor Details

    • SJToolBar

      public SJToolBar()

    • SJToolBar

      public SJToolBar(int orientation)

  • Method Details

    • getOrientation

      public int getOrientation()

    • setOrientation

      public void setOrientation(int orientation)

    • setLayout

      public void setLayout(LayoutManager mgr)
      Hard-pinned flex flow per orientation. R_vaadin_first drop-and-WARN — see class javadoc §"Pinned flex CSS" for why we don't honour user LayoutManager swaps. null is silently accepted since Container.removeAll and similar JDK code paths pass it as a normal teardown step.
      Specified by:
      setLayout in interface ContainerMixin

    • addSeparator

      public void addSeparator()
      Push a thin bar oriented perpendicular to the toolbar axis. Same visual shape an SJSeparator has as a flex child of a toolbar row — Lumo-toned 1px line that align-self:stretches across the cross axis.

    • addSeparator

      public void addSeparator(Dimension size)
      Dimension-sized separator overload. We accept the dimension and drop it per R_layouts_close_enough (no pixel-accurate layout); the visual output matches addSeparator(). JDK uses the size as a gap hint for the L&F-painted separator; migrated code rarely depends on the gap being exactly that many pixels.

    • setMargin

      public void setMargin(Insets m)
      Write padding: top right bottom left on the host element. null removes the property — matches JDK's "use L&F default" semantics, which here means no padding. Fires "margin" PCE on actual change.

    • getMargin

      public Insets getMargin()
      Returns the last-set margin Insets, or null if never set.

    • getUIClassID

      public String getUIClassID()
      Swing constant for L&F lookup; ToolBarUI isn't pluggable here.
      Specified by:
      getUIClassID in interface JComponentMixin

    • updateUI

      public void updateUI()
      L&F swap — no-op for us; Vaadin owns the DOM.
      Specified by:
      updateUI in interface JComponentMixin

    • setUI

      public void setUI(ToolBarUI ui)
      L&F surgery isn't modelled; WARN so integration gaps surface.

    • paramString

      protected String paramString()
      JDK JToolBar.paramString appends paintBorder + margin + floatable. None of those round-trip on the surrogate (floatable/borderPainted are emulator-only; margin lives here but is rendered via CSS). The pure-surrogate paramString tail is empty.

    • getAccessibleContext

      public AccessibleContext getAccessibleContext()