Files
sdrtrunk/settings.gradle
Akumas_Coffin_ af5dbcfcdc Dark mode (#2411)
* Add dark mode toggle under User Preferences > Application

- Add darkMode boolean preference to ApplicationPreference (persisted via java.util.prefs)
- Add ToggleSwitch labeled "Dark Mode" to ApplicationPreferenceEditor
- Add ThemeManager singleton that listens for preference updates and applies/removes
  the dark stylesheet to all registered JavaFX Scenes and swaps the Swing LAF
- Add sdrtrunk_dark.css with dark styling for controls, tables, menus, dialogs, charts
- Add FlatLaf dependency for full Swing dark theming (replaces previous OS-specific
  MetalLookAndFeel setup; FlatLaf works cross-platform)
- Register all Stages created in JavaFxWindowManager with the ThemeManager and walk
  Window.getWindows() at apply-time so unregistered dialogs/alerts also pick up the theme
- Add Foojay toolchain resolver to settings.gradle so Gradle can auto-provision JDK 25

* Fix dark-mode startup failures on Linux

- Apply Swing LAF synchronously on the calling thread so the main JFrame's RootPane
  has a populated UIDefaults set when constructed.  Previously the LAF install was
  scheduled via EventQueue.invokeLater, so JFrame construction raced ahead and threw
  "no ComponentUI class for: javax.swing.JPanel".
- Call LookAndFeelFactory.installJideExtension(VSNET_STYLE) with an explicit style
  instead of the no-arg auto-detection variant.  The auto-detection path probes
  com.sun.java.swing.plaf.windows.WindowsLookAndFeel via Class.forName, which is
  absent on non-Windows JDKs and threw ClassNotFoundException at startup.
- Bounce only the SwingUtilities.updateComponentTreeUI walk through the EDT so it
  redraws already-realized windows on theme toggle.

* Fix JIDE/Windows-LookAndFeel crash on non-Windows JDKs

JIDE 3.6.18's LookAndFeelFactory contains compile-time
\`instanceof com.sun.java.swing.plaf.windows.WindowsLookAndFeel\` checks in
multiple methods, including a JIDE PropertyChangeListener that fires on every
UIManager.setLookAndFeel call.  On Linux and macOS JDKs the class is genuinely
absent from java.desktop, so the JVM throws NoClassDefFoundError the first time
JIDE's dispatch code is executed (during JFrame init and again from
JideSplitPane.updateUI on each LAF change).

Two complementary fixes:

1. Pass an explicit MetalLookAndFeel instance to the 3-arg
   installJideExtension(UIDefaults, LookAndFeel, int) overload so JIDE's Metal
   branch matches first and never falls through to the Windows branch in the
   normal install path.

2. Add a no-op stub class at com.sun.java.swing.plaf.windows.WindowsLookAndFeel
   so that the compile-time class reference resolves on non-Windows JDKs.  The
   stub reports isSupportedLookAndFeel = false and is never instantiated -
   JIDE only uses it for instanceof comparisons against the active LAF, which
   always return false in our setup.  On Windows JDKs the real class in
   java.desktop is loaded by the platform classloader and shadows this stub.

* Re-apply FlatLaf defaults after JIDE install + strengthen FX borders

Symptom: With dark mode enabled, the Swing main window's spectrum chrome and
menu bar were dark (FlatLaf) but tables, tabbed panes and the inner content
area were light/Metal coloured.

Root cause: LookAndFeelFactory.installJideExtension installs JIDE's
Metal-flavored UI defaults (VsnetMetalUtils etc.) into the live UIDefaults
table, overwriting FlatLaf's standard component colors and fonts for keys
like Table.background, TabbedPane.foreground, Panel.background.

Fix: After the JIDE install, walk a fresh FlatLaf UIDefaults table and put
every key back into the active defaults, skipping anything Jide-prefixed.
JIDE's UI delegate registrations live under Jide* keys that FlatLaf does
not define, so they survive untouched while the standard Swing color and
font keys are restored to their dark equivalents.

Also strengthen the JavaFX dark stylesheet: explicit borders on text fields,
tables, titled panes, split-pane dividers and separators so components have
more defining outlines in dark mode.

* Force-override Swing foreground colors via UIManager user-defaults layer

Symptom: With dark mode enabled the inner Swing content area now had dark
panels (good) but tab labels, table cells, status-bar labels and button
text were rendering nearly black-on-dark (bad).

Root cause: UIManager.getLookAndFeelDefaults() lookups for FlatLaf's
component foreground keys still resolve to Metal-era dark values after the
JIDE install + FlatLaf re-apply, because some FlatLaf keys are derived /
LazyValue and recompute against state that JIDE seeded.

Fix: After the bulk FlatLaf-defaults copy, explicitly UIManager.put the
foreground / background / selection / disabled / border colors for every
standard Swing component family.  UIManager.put writes to the user-defaults
layer that takes precedence over the LAF defaults, so these overrides win
regardless of what JIDE or derived-value resolution produces.

Also bump the JavaFX dark stylesheet text colour from #d6d6d6 to #ececec so
labels read closer to white on the dark panels.

* Theme JIDE-specific UIManager keys so JideTabbedPane reads dark colors

The Now Playing / Map / Tuners / Playlist Editor / Details / Events /
Messages / Channel tabs are JIDE JideTabbedPane components and their UI
delegate reads JideTabbedPane.* UIManager keys, not the standard
TabbedPane.* keys.  The previous overrides only set the standard keys so
the tabs were still rendering with JIDE's Metal-era dark foreground on
the now-dark background.

Override the JIDE-specific text foreground keys
(JideTabbedPane.foreground, .selectedTabTextForeground,
.unselectedTabTextForeground, .activeTabTextForeground) along with the
matching background and shadow keys.  Also theme JideSplitPane,
JideButton and JideLabel keys for consistency.

* Remove hardcoded Color.BLACK foreground on JideTabbedPanes

ControllerPanel.getTabbedPane() and NowPlayingPanel.getTabbedPane() each
called setForeground(Color.BLACK) on their JideTabbedPane instances.

Color.BLACK is a plain java.awt.Color, not a ColorUIResource, so it is
never replaced by LookAndFeel.installColorsAndFont() on subsequent UI
installs - it permanently pins the tab labels to black regardless of any
JIDE or FlatLaf defaults the theme manager sets.  In dark mode this leaves
the tab labels black-on-dark and unreadable.

Drop the explicit foreground calls so the LAF (JideTabbedPaneUI reading
JideTabbedPane.foreground / .unselectedTabTextForeground /
.selectedTabTextForeground / .activeTabTextForeground) drives the colour
in both light and dark modes.

* Register Channel tab's JFXPanel scenes with the ThemeManager

The Channel tab embeds two JavaFX scenes inside Swing via JFXPanel: the
noise squelch chart (NoiseSquelchView) and the symbol view.  Neither was
registered with the ThemeManager, so the dark stylesheet was never applied
to them.  In dark mode the chart legend, axis area and surrounding panel
rendered with JavaFX's default light Modena styling against the otherwise
dark UI.

JFXPanel-hosted scenes are invisible to javafx.stage.Window.getWindows(),
so the theme manager cannot find them automatically on toggle - they have
to be explicitly registered at creation time, the same as the JavaFX
Stages JavaFxWindowManager already registers.

* Use ColorUIResource for theme overrides + brighten chart series colors

Toggle-off problem: applyExplicitOverrides was storing plain java.awt.Color
values via UIManager.put.  LookAndFeel.installColorsAndFont only replaces a
component's existing colour when it is null or an instance of UIResource -
plain Colors are not, so once a component picked up its dark colour it kept
that colour for the rest of the JVM lifetime even after toggling back to
light mode.  Switching every override to ColorUIResource lets subsequent
updateComponentTreeUI calls replace the cached colour cleanly.

Chart visibility: the JavaFX charts on the Channel tab (NoiseSquelchView)
were inheriting Modena's default 8-colour series palette, which has several
hues that read poorly against a dark plot background.  The existing
sdrtrunk_style.css also hardcodes .chart-symbol to solid black.  Override
.default-color0..7.chart-series-line and matching .chart-line-symbol selectors
with a brighter high-contrast palette, darken the plot background to #1c1c1c
for stronger contrast against the grid lines, and add explicit colours for
axis tick marks, alternate row fills and legend border.

* Use primary foreground for selected tab text instead of selection foreground

The previous overrides set JideTabbedPane.selectedTabTextForeground and
TabbedPane.selectedForeground to fgSelection (always white).  Selected tabs
render on the raised surface (bgRaised) which is white in light mode, so
white-on-white made selected tab labels invisible.

Selected tabs are not list/table row selections that use the blue
bgSelection background - they sit on the same raised tone as other surfaces.
Use fgPrimary so the text is dark on the light raised surface in light mode
and light on the dark raised surface in dark mode.

* Brighten chart data points to solid white in dark mode

* Restore default chart symbol size, only override colour

* Refresh detached Channel-tab swing components on theme toggle

The Channel tab swaps one of three right-pane components into its
JSplitPane depending on the active decoder type: SignalPowerView for AM,
the NoiseSquelchPanel JFXPanel for NBFM, the SymbolPanel JFXPanel for
feedback decoders.  Only one is attached at any moment - the other two
are detached references on the ChannelSpectrumPanel.

SwingUtilities.updateComponentTreeUI(Window) during a theme toggle walks
only the currently-realized component trees, so the detached swappables
miss the refresh and carry stale colours from the LAF that was active
when they were last attached.  Swapping back in then shows e.g. an AM
SignalPowerView in dark colours after a light-mode toggle.

Add ThemeManager.registerSwing(Component) tracking, walk those refs on
every toggle, and register the three swappables when constructed.

* Add preset themes selector under User Preferences > Application

Replace the single Dark Mode toggle with a curated selection of 9 preset
themes, exposed as a vertical radio-button group:

  Light                IntelliJ              Nord
  Dark                 Darcula               Dracula
  Solarized Light      Solarized Dark        Monokai Pro

Each Theme enum value pairs a human-readable display name with a FlatLaf
class name and a dark flag.  The first four come from the core flatlaf
dependency; the others come from flatlaf-intellij-themes which is added
as a new implementation dependency (~1MB).

ApplicationPreference now stores the selected theme by enum name under
the new ui.theme key.  isDarkMode() is retained as a compatibility shim
that delegates to the current theme.  Existing users with the legacy
dark.mode boolean are auto-migrated on first read.

ThemeManager is refactored to drive the LAF from the Theme:
- Reflectively instantiates the FlatLaf class.
- Reads Panel.background, Button.background, TextField.background,
  List.selectionBackground/Foreground, Label.foreground/disabledForeground,
  Component.borderColor and Table.alternateRowColor from UIManager *after*
  FlatLaf installs, then seeds those values into the JIDE-specific keys.
  Each theme automatically contributes its own palette to JIDE widgets
  without per-theme hardcoded colours.

ApplicationPreferenceEditor swaps the ToggleSwitch for a ToggleGroup of
RadioButtons that persist the selection through ApplicationPreference.setTheme.

* Fix theme switching past first toggle + move Themes to Appearance sub-page

Critical regression in 56b0f6c9: applyExplicitOverrides reads colours via
UIManager.getColor(...) which consults the merged defaults (user defaults
overlay LAF defaults).  After the first apply our own UIManager.put calls
populate the user-defaults layer, so subsequent reads return our previous
theme's colours instead of the newly-installed LAF's colours.  The result:
the first theme switch works, every switch after that silently re-applies
the previous palette and the UI appears frozen on the first picked theme.

Switch every palette read to UIManager.getLookAndFeelDefaults().getColor(...)
which is the LAF-only layer and ignores the user-defaults overlay we wrote.

Also:
- Move the Themes selector to its own sub-node:
    User Preferences > Application > Appearance
  PreferenceEditorType gets a new APPEARANCE entry, the existing APPLICATION
  leaf is relabelled "General" so the tree no longer reads "Application >
  Application > Application".  New AppearancePreferenceEditor hosts the theme
  radio group; ApplicationPreferenceEditor loses it.

- Replace a few hardcoded label foregrounds that read as
  invisible-on-dark-bg with LAF-driven equivalents:
    TunerViewPanel TunerStatus.DISABLED: DARK_GRAY -> Label.disabledForeground
    BroadcastStatusPanel DISABLED state: LIGHT_GRAY -> Label.disabledForeground
    JFrequencyControl Digit mouseExited:   Color.WHITE -> TextField.background

  Semantic colour usage (RED/YELLOW for error and warning states, the
  audio-panel hardware-style black backgrounds) is intentionally kept.

* Auto-theme every JavaFX window so transient dialogs follow the theme

The Playlist Editor's main Scene is already registered with the ThemeManager,
but the many Alert / TextInputDialog / RadioReferenceUnavailableAlert popups
it spawns each create a fresh Stage with a fresh Scene that nothing registers.
Once one is shown after a theme switch it renders with default Modena styling
on top of an otherwise themed app.

Install a ListChangeListener on javafx.stage.Window.getWindows() at startup.
Every newly-added Window is themed immediately if its Scene is set, otherwise
a one-shot sceneProperty listener applies the theme the moment the Scene is
attached.  Already-open windows at install time are also walked once.

This removes the need to manually register every transient dialog and covers
the playlist editor, alias editor confirmations, broadcastify error alerts,
channel-map editor warnings, and any future ad-hoc Alert / Dialog the
codebase grows.

* Curate themes to 8 modern variants + per-theme JavaFX accent colours

Theme set is trimmed and refocused:
  Drop:  IntelliJ (too similar to Light), FlatDarculaLaf (duplicates Dracula),
         Monokai Pro (low identity in this app).
  Add:   Material Deep Ocean (vibrant teal dark), Arc Dark (flat modern dark).
  Keep:  Light, Dark, Nord, Dracula (FlatDraculaIJTheme - the one user liked),
         Solarized Light, Solarized Dark.

Each theme now contributes its own accent palette to the JavaFX panels too,
not just the Swing chrome.  ThemeManager builds a small per-theme stylesheet
at apply time by reading the FlatLaf-installed colours (Panel.background,
TextField.background, Component.accentColor, List.selectionBackground/Foreground,
Label.foreground, Component.borderColor, Table.alternateRowColor) and
substituting them into Modena's core variables (-fx-base, -fx-accent,
-fx-selection-bar, -fx-control-inner-background, etc.) plus a handful of
explicit rules for table selection rows, default button, scroll bar thumb.

The generated CSS is attached to every registered Scene as a data: URL, so
Nord reads blue-tinted, Dracula purple-tinted, Solarized cream/teal,
Material Deep Ocean dark teal, Arc Dark cool gray.  The static
sdrtrunk_dark.css remains as the structural baseline for all dark themes.

* Add GUI scale slider under Appearance preferences

New slider in User Preferences > Application > Appearance lets users zoom
the whole UI between 50% and 200% in 10% increments.  The value is
persisted as a new ApplicationPreference (ui.gui.scale, default 1.0,
bounded 0.5-2.0) and applied immediately on slider release - intermediate
drag positions do not trigger a re-apply so the LAF reinstall cost is
paid once at the end of the drag.

Swing side: ThemeManager sets the flatlaf.uiScale system property before
each setLookAndFeel call, so the new FlatLaf instance picks up the user's
zoom on initialise.  All component sizes (fonts, padding, icons) scale
together because FlatLaf does the math internally.

JavaFX side: the per-theme accent stylesheet emits an
  .root { -fx-font-size: <12 * scale>px; }
rule.  Modena's component sizes are em-relative so cascading the font
size scales the JavaFX panels in sync with the Swing chrome.

The onPreferenceUpdated guard now compares both theme and scale, so
moving only the slider still triggers a re-apply.  A Reset button next
to the slider returns to 100%.
2026-07-31 04:20:40 -04:00

5 lines
117 B
Groovy

plugins {
id 'org.gradle.toolchains.foojay-resolver-convention' version '1.0.0'
}
rootProject.name = 'sdr-trunk'