It gives me great pleasure to announce the seventh major release of Radiance. Let’s get to what’s been fixed, and what’s been added. First, I’m going to use emojis to mark different parts of it like this:

💔 marks an incompatible API / binary change
🎁 marks new features
🔧 marks bug fixes and general improvements

Dependencies for core libraries

  • Gradle from 7.1 to 7.2
  • Kotlin from 1.5.10 to 1.5.31
  • Kotlin coroutines from 1.5.0 to 1.5.2

Neon

Substance

Flamingo

  • 🎁💔 Add reference to the ribbon as a parameter to all OnShowContextualMenuListener methods
  • 🎁💔 Align icon theming across all Flamingo components
  • 🔧 Fix layout of command buttons in TILE layout under RTL
  • 🔧 Fix visuals of horizontal command button strips under RTL
  • 🔧 Fix layout of anchored command buttons under RTL
  • 🔧 Fix layout of command button popup content under RTL
  • 🔧 Fix issues with updating ribbon gallery content

Photon

  • 💔 Remove SvgBatikIcon and SvgBatikNeonIcon
  • 💔 Move Photon to be under tools

General

As with the earlier release 4.0.0, this release has mostly been focused on stabilizing and improving the overall API surface of the various Radiance modules. As always, I’d love for you to take this Radiance release for a spin. Click here to get the instructions on how to add Radiance to your builds. And don’t forget that all of the modules require Java 9 to build and run.

And now for the next big thing or two.

I will take the next two weeks to fix any bugs or regressions that are reported on the 4.5.0 release. On the week of October 18th, all Radiance modules are going to undergo a major refactoring. While Radiance unified all of the Swing projects that I’ve been working on since around 2004, this unification was rather superficial. It made it easier to have inter-module dependencies. It made it easier to write documentation. It made it easier to schedule coordinated releases. But it didn’t make it easier to see what Radiance is.

In the last year or so I kept on asking myself the same questions over and over again.

If I started with these libraries today, will they still be using these disjointed codenames (Neon, Trident, Substance, Flamingo, not to talk about Torch, Apollo, Zodiac, Meteor, Ember, Plasma, Spyglass, Beacon, etc)? For somebody who wants to deep dive into the implementation details, are there places that are internally inconsistent? For an app developer who wants to get the most out of these libraries, does Radiance provide an externally approachable and consistent set of APIs?

The first step I’m taking to answer at least some of these questions is moving away from the codenames, and renaming everything based on the functional boundaries. And by everything I mean everything – modules, classes, methods, fields, variables, etc. It’s going to be a huge breaking change. But it’s something that I feel is way overdue for a project of this complexity. More specifically:

  • org.pushingpixels.trident -> org.pushingpixels.radiance.animation
  • org.pushingpixels.neon -> org.pushingpixels.radiance.common
  • org.pushingpixels.substance -> org.pushingpixels.radiance.theming
  • org.pushingpixels.flamingo -> org.pushingpixels.radiance.component
  • org.pushingpixels.substance.extras -> org.pushingpixels.radiance.theming.extras
  • org.pushingpixels.ember -> org.pushingpixels.radiance.theming.ktx
  • org.pushingpixels.meteor -> org.pushingpixels.radiance.swing.ktx
  • org.pushingpixels.plasma -> org.pushingpixels.radiance.component.ktx
  • org.pushingpixels.torch -> org.pushingpixels.radiance.animation.ktx
  • org.pushingpixels.tools.apollo -> org.pushingpixels.radiance.tools.schemeeditor
  • org.pushingpixels.tools.beacon -> org.pushingpixels.radiance.tools.themingdebugger
  • org.pushingpixels.tools.hyperion -> org.pushingpixels.radiance.tools.shapereditor
  • org.pushingpixels.tools.ignite -> org.pushingpixels.radiance.tools.svgtranscoder.gradle
  • org.pushingpixels.tools.lightbeam -> org.pushingpixels.radiance.tools.lafbenchmark
  • org.pushingpixels.tools.photon -> org.pushingpixels.radiance.tools.svgtranscoder
  • org.pushingpixels.tools.zodiac -> org.pushingpixels.radiance.tools.screenshot

Classes that used codenames, such as SubstanceLookAndFeel, TridentConfig etc will be renamed to follow the functionality of the matching API sub-surface. For example:

  • SubstanceCortex -> RadianceLafCortex
  • TridentCortex -> RadianceAnimationCortex
  • SubstanceButtonUI -> RadianceButtonUI

This first round of refactoring will be the next Radiance release. It will not move classes between modules. It will not add or remove modules, classes or methods. Migrating from 4.5 to 5.0 will require a lot of import refactoring, and some amount of refactoring – wherever you are calling Radiance APIs in your code. Once 5.0 is out, the next release will have follow-up refactorings for cleaning up places that have not aged well.

What’s the other big thing that I alluded to earlier? I want to provide support for consistent application of custom visuals across all supported Swing components. In Substance, this is done with painters. Due to a complicated nature of some of these painters, pretty much since the very beginning Substance has been using cached off-screen bitmaps to maintain a good performance footprint. The very first time a component needs to be rendered in a certain visual state, Substance renders those visuals to an offscreen bitmap. Next time, if we already have a cached bitmap that matches the current state, we reuse it by rendering that bitmap on the screen.

While this model has served Substance (and, by extension, the Flamingo components) rather well, it has started to show significant cracks over the last few years. You can see more information in this bug tracker on the underlying issues, but the gist of it is rather simple – screens with fractional DPI settings (125% or 150%, for example) do not play well with rendering offscreen bitmaps. The end result is that rendering a hairline (one-pixel wide) element can be fuzzy, distorted, or not there at all on the screen.

It is going to be a long road, and it might mean that it might take longer than usual to get the next Radiance release out the door. My current goal is that by the end of it, Radiance does not use any offscreen bitmaps for any of its rendering, and that everything is rendered directly onto the passed graphics object. Lightbeam will certainly come in handy all through that process. Wait, excuse me, Lightbeam will be no more in a couple weeks. It’s going to be Radiance LAF Benchmark instead.

 

Radiance 4.0.0

June 17th, 2021

It gives me great pleasure to announce the sixth major release of Radiance. Let’s get to what’s been fixed, and what’s been added. First, I’m going to use emojis to mark different parts of it like this:

💔 marks an incompatible API / binary change
🎁 marks new features
🔧 marks bug fixes and general improvements

Dependencies for core libraries

  • Gradle from 6.6.1 to 7.1
  • Kotlin from 1.4.10 to 1.5.10
  • Kotlin coroutines from 1.3.9 to 1.5.0

Substance

Flamingo

  • 🎁 Add support for keyboard accelerators on ribbon commands
  • 🔧 Fix ribbon application menu border color on skin switch
  • 🔧 Fix exception on skin switch when the ribbon application menu is not shown
  • 🔧 Fix for various visuals on multi-monitor setup with different screen densities
  • 🔧 Fix even-odd coloring of command button panel groups
  • 💔 Tweak implementation of FIT_TO_ICON command button layout manager

Trident

  • 💔 Rename TridentConfig to TridentCortex

As with the earlier release 3.5.0, this release has mostly been focused on stabilizing and improving the overall API surface of the various Radiance modules. There’s still a long road ahead to continue exploring the never-ending depths of what it takes to write elegant and high-performing desktop applications in Swing. If you’re in the business of writing just such apps, I’d love for you to take this Radiance release for a spin. Click here to get the instructions on how to add Radiance to your builds. And don’t forget that all of the modules require Java 9 to build and run.

Radiance 3.5.0

October 5th, 2020

It gives me great pleasure to announce the fifth major release of Radiance. Let’s get to what’s been fixed, and what’s been added. First, I’m going to use emojis to mark different parts of it like this:

💔 marks an incompatible API / binary change
😻 marks new features
🤷‍♀️ marks bug fixes and general improvements

Dependencies for core libraries

  • Gradle from 6.4.1 to 6.6.1
  • Kotlin from 1.3.72 to 1.4.10
  • Kotlin coroutines from 1.3.7 to 1.3.9

Substance

  • 💔 Remove support for watermarks
  • 💔 Convert SubstanceSkin.ColorSchemes into an interface
  • 😻 Support for overlay colors with SubstanceSkin.setOverlayColor
  • 💔 Support for specifying derived colors in color scheme files
  • 😻 New API to mark a label as title pane text
  • 😻 Text highlights that respect decoration areas
  • 💔 Moved the Green Magic skin from substance-extras to the core substance module (see the screenshot of this skin above)
  • 💔 Aligned signatures of ComponentState.getActiveStates and ComponentState.getAllStates
  • 🤷‍♀️ Improved menu search widget UX
  • 🤷‍♀️ Correct layout for edit context menu under RTL
  • 🤷‍♀️ Fix concurrent modification exception thrown when ghost icon animations are enabled

Flamingo

  • 💔 Pass command projection instead of command in ribbon contextual menu listener
  • 💔 Remove AbstractCommandButton class. Everything is in the JCommandButton class now.
  • 😻 New CommandButtonPresentationModel.Builder.setPopupHorizontalGravity API to contol horizontal alignment of command button popups
  • 🤷‍♀️ Fix crash in opening a command popup menu from taskbar
  • 🤷‍♀️ Fix memory leaks caused by model listeners
  • 🤷‍♀️ Fix for root key tip chain not showing popup key tips of anchored commands
  • 🤷‍♀️ Fix for overlays on ribbon popup content in the title pane / taskbar

Trident

  • 🤷‍♀️ Fix inconsistent usage of conversion from duration fraction to timeline position

This release has mostly been focused on stabilizing and improving the overall API surface of the various Radiance modules. There’s still a long road ahead to continue exploring the never-ending depths of what it takes to write elegant and high-performing desktop applications in Swing. If you’re in the business of writing just such apps, I’d love for you to take this Radiance release for a spin. Click here to get the instructions on how to add Radiance to your builds. And don’t forget that all of the modules require Java 9 to build and run.

 

Radiance 3.0.0

May 31st, 2020

It gives me great pleasure to announce the fourth major release of Radiance. Let’s get to what’s been fixed, and what’s been added. First, I’m going to use emojis to mark different parts of it like this:

💔 marks an incompatible API / binary change
😻 marks new features
🤷‍♀️ marks bug fixes and general improvements

Dependencies for core libraries

  • Gradle from 5.6.1 to 6.4.1
  • Kotlin from 1.3.50 to 1.3.72
  • Kotlin coroutines from 1.3.0 to 1.3.7
  • Batik from 1.11 to 1.13

Substance

  • 😻 A more flexible skin accent system
  • 😻 New skins – Graphite Sienna, Sentinel and Harvest
  • 😻 Support color references in color scheme files
  • 😻 New Caps Lock indication on focused password fields
  • 😻 New association kind for checkbox and radio button “boxes”
  • 💔 Revisit APIs for loading color scheme bundles
  • 💔 Remove the title pane heap status widget
  • 🤷‍♀️ Use Helvetica Neue on macOS Catalina
  • 🤷‍♀️ Visual refresh of checkbox marks
  • 🤷‍♀️ Support for fallback fonts (CJK, etc)
  • 🤷‍♀️ Fix for incorrect usage of HIGHLIGHT_TEXT association kind on renderers.
  • 🤷‍♀️ Fix for background of popup menus opened from toolbar buttons.
  • 🤷‍♀️ Fix improved contrast across core skins.
  • 🤷‍♀️ Multiple fixes for table rollover hightlights and animations
  • 🤷‍♀️ Fix for some components under very large font sizes
  • 🤷‍♀️ Performance fix for column selection in large tables
  • 🤷‍♀️ Fix for icons in file chooser drop downs
  • 🤷‍♀️ Fix for incorrect bounds of maximized frames on secondary monitors

Flamingo

  • 💔 General evolution of command button APIs
  • 😻 Support for toggle split buttons
  • 😻 Add API to wire notification on ribbon spinner changes
  • 😻 Add API to wire notification on ribbon task selection
  • 🤷‍♀️ Multiple focus traversal fixes for ribbon content
  • 🤷‍♀️ Fixes for clipped wrapped ribbon components
  • 🤷‍♀️ Fix to not use round corners on command buttons in menus
  • 🤷‍♀️ Fix for crash in narrow command button panels
  • 🤷‍♀️ Fix for crash in showing keytips on toggle anchored ribbon commands
  • 🤷‍♀️ Fix for crash on showing keytips on undecorated windows
  • 🤷‍♀️ Fix for dynamic changes to ribbon gallery content
  • 🤷‍♀️ Fix for large icons on internal frames
  • 🤷‍♀️ Use the public Taskbar API to set the ribbon frame dock icon

Trident

  • 💔 Move all public APIs to org.pushingpixels.trident.api package
  • 💔 Remove generic UI toolkit support and leave only Swing support
  • 😻 Add support to provide dynamically computed from / to values on timelines.

Neon

  • 💔 Move all public APIs to org.pushingpixels.neon.api package

Photon

Plasma

This release marks a special milestone for me. The very first Substance release happened exactly fifteen years ago, on May 30th 2005. I didn’t quite imagine that I’d be here today, still working on the same codebase.

There’s still a long road ahead to continue exploring the never-ending depths of what it takes to write elegant and high-performing desktop applications in Swing. If you’re in the business of writing just such apps, I’d love for you to take this Radiance release for a spin. Click here to get the instructions on how to add Radiance to your builds. And don’t forget that all of the modules require Java 9 to build and run.

Here’s to the next fifteen years!