Going with the new biannual release cycle of my Swing projects, it’s time to do the release candidates for the latest iterations.

The first major pillar for Substance 8.0 (code-named Wyoming) is Project Cerebrum – unified API surface. The API surface for controlling the visual appearance and behavior of various parts of Substance has grown organically over the years. Part of this growth process has been experimenting with various ways to express this control, from client properties to VM flags to APIs on a number of classes.

Starting with 8.0, the only officially supported entry point into configuring the behavior of Substance-powered UIs and for querying the state of such UIs is via the org.pushingpixels.substance.api.SubstanceCortex class. The API surface of this class is broken into a number of scopes, with every scope applying at the specific granularity level of control

The second major pillar is Project Visor – configurable and custom title pane content. It provides a number of APIs to configure the layout in and around the title pane area of application windows. SubstanceCortex.GlobalScope.configureTitleContentGravity is the API to globally configure the gravity (edge alignment) of title pane content – title text, control buttons (minimize, maximize, close) and app icon.

The following APIs on the SubstanceCortex.WindowScope scope allow apps to extend the main content view into the title pane area – as can be seen in all the screenshots in this post:

• extendContentIntoTitlePane(Window, SubstanceSlices.HorizontalGravity, SubstanceSlices.VerticalGravity) to marks the specified window to have its content extend vertically into the title pane area.
• getTitlePaneControlInsets(Window) to query the insets that should be reserved for the main control buttons – close / maximize / minimize.
• setPreferredTitlePaneHeight(Window, int) to increase the preferred height of the title pane area in case the content you extend into that area is taller than the main control buttons.
• createTitlePaneControlButton(Window) to get a button that has consistent visual appearance and preferred size with the main control buttons.

Calling JFrame.setDefaultLookAndFeelDecorated(true) on the specific window is the mandatory pre-requisite to be extend the window content into the title pane area with SubstanceCortex.WindowScope.extendContentIntoTitlePane API. See the skeleton demo apps for sample code on how to use these APIs.

The third major pillar is Project Corpora. Up until version 8.0, Substance used to depend on laf-plugin and laf-widget. Those two projects were envisioned when the landscape of third party look-and-feels in particular, and Swing in general, was more vibrant. The goal was:

• For laf-plugin to provide a common mechanism for specifying look-and-feel plugins for components libraries
• For laf-widget to provide a collection of widgets that enhance the visual appearance and behavior of specific Swing components

The functionality of these two projects has now been folded into the main Substance codebase. The APIs for configuring animations and widgets are now part of the SubstanceCortex class

In addition, Substance 8.0 comes with:

• Consistent package names for public APIs
• Removed automatic discovery of Substance plugins (that could be used for injecting unintended behaviors into Swing apps powered by Substance)
• Switch to Material icons for built-in components
• Support for icon packs
• Better support for fractional desktop scaling factors

Full release notes for Substance 8.0 are available here.

The biggest change in Flamingo 5.3 (code-named Liadan) is separating the non-core functionality into two new projects:

• Ibis has the code for using vector-based icons in Swing apps. It supports offline transcoding of SVG content into Java2D-powered classes, as well as dynamic display of SVG content at runtime (powered by the latest version of Apache Batik)
• Spoonbill has the code for browsing SVN repositories with the JBreadcrumbBar component from the core Flamingo project. Future plans include extending this functionality to GitHub repositories as well.

If you’re in the business of writing Swing desktop applications, I’d love for you to take the latest release candidates of Substance and Flamingo for a spin. You can find the downloads in the /drop folders of the matching Github repositories. All of them require Java 8 to build and run. The final releases are scheduled to happen in two weeks’ time, on the week of March 11th.

Going with the new biannual release cycle of my Swing projects, this week is seeing the latest official releases of Substance and Flamingo.

Along with a few visual polishes and tweaks, Substance 7.1 (code-named Vermont) brings support for using correct default system font on macOS 10.10+ when you’re running your app under the recently-released Java 9. In addition, your JOptionPanes will see a tweaked order and alignment of the buttons. By default, the order and alignment follows the interface guidelines for the specific platform. On a macOS machine, for example, the buttons will be aligned to the trailing edge of the dialog (right on LTR and left on RTL), with the default button placed as the trailing button:

Use the APIs on the SubstanceLookAndFeel class for app-specific control over the order and alignment of the JOptionPane buttons if you want to deviate from the platform guidelines.

The previous release of Substance brought full support for high DPI screens, and the latest release for Flamingo 5.2 (code-named Kennocha) aligns both libraries to be first class citizens on modern screen hardware. The unofficial release notes are:

• Full high DPI support for all components, including
  • Command button icons and arrows
  • Color selector popup menu
  • Ribbon galleries
  • Ribbon bands in collapsed state
• Support for vertical scrolling of secondary level content in ribbon application menu
• Better mouse wheel handling in command menu popups
• Addressed clipping issues on some transcoded SVG content

If you’re in the business of writing Swing desktop applications, I’d love for you to take the latest releases of Substance and Flamingo for a spin. You can find the downloads in the /drop folders of the matching Github repositories. All of them require Java 8 to build and run. Happy Swing coding!

Going with the new biannual release cycle of my Swing projects, it’s time to do the release candidates for the latest iterations of Substance and Flamingo.

Along with a few visual polishes and tweaks, Substance 7.1 (code-named Vermont) brings support for using correct default system font on macOS 10.10+ when you’re running your app under the recently-released Java 9.

The previous release of Substance brought full support for high DPI screens, and the latest release candidate for Flamingo 5.2 (code-named Kennocha) aligns both libraries to be first class citizens on modern screen hardware. The unofficial release notes are:

• Full high DPI support for all components, including
  • Command button icons and arrows
  • Color selector popup menu
  • Ribbon galleries
  • Ribbon bands in collapsed state
• Support for vertical scrolling of secondary level content in ribbon application menu
• Better mouse wheel handling in command menu popups
• Addressed clipping issues on some transcoded SVG content

If you’re in the business of writing Swing desktop applications, I’d love for you to take the latest release candidates of Substance and Flamingo for a spin. You can find the downloads in the /drop folders of the matching Github repositories. All of them require Java 8 to build and run. The final releases are scheduled to happen in two weeks’ time, on the week of October 16th.

See the recent follow-up on the changes to the font family name on Catalina and changes needed at the JRE level to support proper kerning.

Starting from OS X El Capitan (10.11), there’s a new default system font in town – San Francisco. And it came with a very big underlying change, as detailed by Craig Hockenberry:

Apple has started abstracting the idea of a system font: it doesn’t have a publicly exposed name. They’ve also stated that any private names are subject to change. These private names all begin with a period: the Ultralight face for San Francisco is named “.SFNSDisplay-Ultralight”. To determine this name, you need to dig around in the font instances returned by NSFont or UIFont; it’s not easy by design.

The motivation for this abstraction is so the operating system can make better choices on which face to use at a given weight. Apple is also working on font features, such as selectable “6” and “9” glyphs or non-monospaced numbers. It’s my guess that they’d like to bring these features to the web, as well.

Even though the underlying .otf files are still in /System/Library/Fonts, San Francisco is no longer exposed via the regular APIs that web and desktop developers have grown used to. Specifically for Swing developers (of which there may not be many, so at some point it will kind of take care of itself), passing “San Francisco” to the Font constructor ends up using the previous default – Lucida Grande.

JavaFX is already doing the right thing, using San Francisco as the default UI font on El Capitan and Sierra. Swing’s legacy is to have each look-and-feel decide which font to use, and I was expecting the “System” look-and-feel which maps to Aqua to be using the right font family on the latest OS releases. That is not the case as I’m writing this entry, and Swing apps on both El Capitan and Sierra are still using Lucida Grande on both 8u112 and 9-ea.

Last week Phil Race pointed me to this issue that tracked syncing up the internal implementation details of glyph mapping between JavaFX and AWT. That issue has been fixed in early access builds of JDK 9, and is slated to be available in JDK 8 u152 scheduled for October 2017. At the present moment there is no public API to get either a name or a font instance itself that will be mapped to Lucida Grande on 10.10 and earlier, and to San Francisco on 10.11 and 10.12. The only available solution is quite brittle as it depends on the internal naming conventions exposed by the underlying OS:

• .Helvetica Neue DeskInterface on El Capitan (10.11)
• .SF NS Text on Sierra (10.12)

Note that you need a leading dot in both cases, and that this only works on early access builds of JDK 9 at the moment:

In this screenshot the second button is using new Font(“.SF NS Text”, Font.PLAIN, 24) while the rest are rendered with Lucida Grande. The most noticeable differences are in the curvy strokes of “e”, “g”, “5” and “9”, as well as the straight leg of “a”.

Ideally, there’d be an officially supported way to use the right font on OS X / macOS, either in a form on some kind of a static Font API or a synthetic font family that maps to the underlying system font on all supported platforms. Phil has filed a bug to track the progress on that front.