Swing Intellij Dialog Style

Swing IntelliJ Dialog Style

Use this skill for EasyPostman Swing dialogs that should feel closer to IntelliJ IDEA: quiet, dense, readable, and clearly separated by behavior rather than decoration.

Use With

• Read swing-flatlaf-miglayout-principles first when the change touches form layout, focus rings, clipping, nested panels, scroll panes, or section borders.
• Read fontsutil-font-usage when changing any label, title, option, table, renderer, or dialog font size.
• Keep reusable controls, icons, fonts, and colors in easy-postman-ui; keep host dialog composition in easy-postman-app.

Core Style

• Prefer dialog-surface backgrounds plus thin separators over large banner headers or heavy cards.
• Treat dialog chrome as separate from app frame/tool-window chrome:
  • Use ModernColors.getDialogChromeBackgroundColor() through ToolWindowSurfaceStyle.applyDialogWindowChrome(...), applyDialogSurface(...), applyDialogSection(...), and applyDialogFooter(...).
  • Do not use or change ModernColors.getWindowChromeBackgroundColor() for dialogs; that belongs to the main frame/menu/title chrome.
  • Light dialog chrome is expected to read near 247,248,249; dark dialog chrome near 25,26,28.
• Do not force full dialog window chrome on sidebar pop-out managers that already own their content header, such as Globals or Cookies. Use ToolWindowSurfaceStyle.skipDialogWindowChrome(dialog) and set the content panel directly; avoid ToolWindowChrome.wrapDialogToolWindow(...) there because it adds an extra titlebar/card shell.
• Keep the split of responsibility clear:
  • FlatLaf .properties and ModernColors own theme tokens and standard component defaults.
  • ToolWindowSurfaceStyle owns reusable styling for custom composite dialog surfaces, scroll panes, list blank areas, headers, and footers.
  • Individual dialog classes should only express layout or renderer behavior that is local to that dialog.
• Keep headers compact: small icon or no icon, title at FontsUtil.getDefaultFontWithOffset(Font.BOLD, +1) or lower, secondary metadata at -1.
• Use one outer border strategy per content region. For IDEA-like sections, use a light line border plus modest inner padding such as 8,10,8,10.
• Avoid nested card-in-card layouts. Use rows, split content, or thin MatteBorder separators.
• Use ModernButtonFactory for dialog footer buttons so Cancel/OK/Apply/primary actions match settings dialogs.
• Use ToolWindowSurfaceStyle.applyDialogFooter(...) for the footer and applyDialogSurface(...) for outer containers.
• Use ToolWindowSurfaceStyle.applyDialogSection(...) for bordered non-edit sections instead of applyCard(...) or applySectionCard(...).
• Use ToolWindowSurfaceStyle.applyTextComponentDialogSurface(...) for read-only text viewers inside dialogs.

Read-Only vs Editable

Make editable controls visibly different from read-only output.

• Read-only output areas:
  • JEditorPane or viewer components should usually use dialog-surface background, no strong input border, and secondary text where appropriate.
  • Add bottom padding inside scroll content so text does not collide with separators or fixed bottom sections.
  • Keep scrollbars narrow and low-contrast when the content is informational.
• Non-edit dialog content:
  • Do not paint large white cards just to group content. Match the dialog chrome background and use separators or applyDialogSection(...) when grouping is necessary.
  • Dialog JList blank areas and read-only list rows should use ToolWindowSurfaceStyle.applyDialogList(...) or applyDialogListScrollPane(...); do not restyle them with applyListCard(...) inside dialogs.
  • Reserve white/light input color for actual editable controls such as JTextField, JTextArea, JPasswordField, JComboBox, and editable table cells.
• Editable inputs:
  • Use input background, visible medium border, and inner padding.
  • Add focus feedback, usually primary-color border on focus.
  • If the surrounding area contains mostly read-only content, label editable sections with a small edit icon such as icons/edit.svg.
  • Preserve FlatLaf focus visibility; do not hide focus rings with wrapper borders.

Typical editable text-area pattern:

ToolWindowSurfaceStyle.applyDialogScrollPane(scrollPane);
textArea.setBorder(new EmptyBorder(5, 8, 5, 8));
scrollPane.setBorder(BorderFactory.createCompoundBorder(
        BorderFactory.createLineBorder(focused ? ModernColors.getPrimary() : ModernColors.getBorderMediumColor()),
        BorderFactory.createEmptyBorder(1, 1, 1, 1)
));

Wizard/Step Areas

• Keep step indicators compact and secondary to the content.
• Use small circular badges, muted inactive labels, and a clear active state.
• Do not let the step strip consume the vertical space needed by the main content.
• If current progress is not actionable, keep it visually quieter than form inputs and action choices.

Scroll And Fixed Sections

• When a scrollable read-only area sits above a fixed editable section, separate them with a thin MatteBorder and add top padding to the fixed section.
• Add bottom padding to the scrollable content so the final line is not visually clipped by the separator.
• Use a modest scrollbar width, for example 8px, for compact informational panes.
• Avoid making scrollbars or empty gutters the strongest visual element in the dialog.
• If a scroll pane contains an editable text area, style the scroll pane as an input border; if it contains read-only content, use dialog-surface scroll styling plus a subtle separator/border only when needed.
• Use JSplitPane only when the user needs to resize sections. For fixed two-column dialog layouts, prefer MigLayout columns and gaps so the split divider does not become a visible artifact.

Action Choices

• For radio-button strategy sections, use a light bordered section with compact title, radio label, and muted description.
• Keep option descriptions smaller with FontsUtil.getDefaultFontWithOffset(Font.ITALIC, -3) or similar.
• Dangerous options can use ModernColors.getError() for the radio label, but avoid large warning blocks unless the action is destructive and easy to trigger.

I18n And Icons

• User-visible text must use I18nUtil.getMessage(...) or the appropriate shared i18n helper.
• Remove decorative emoji from dialog status text; use structure, color, and icons instead.
• Use UI-owned generic icons such as icons/edit.svg through IconUtil.createThemed(...).

Verification

• Compile the app module: mvn -q -pl easy-postman-app -am -DskipTests compile.
• Run focused existing tests when a component has one, for example StepIndicatorTest.
• For editable fields, manually reason or visually verify that the default state, focused state, and disabled state are distinguishable.
• Check Chinese and English labels for truncation and excessive fixed-width assumptions.