Radiance 2.0.1

March 11th, 2019

It gives me great pleasure to announce the second major release of Radiance. It was all ready to go as 2.0.0, but what’s a release really if a blocker bug doesn’t make it in? So instead, you get to get 2.0.1 for now – pending any other blockers that would require a couple more minor re-spins. Anyway, let’s get to what’s new. 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

General

  • 💔 Java 9 is the new minimum requirement for build time and runtime of all Radiance modules

Modules

  • 💔 Removed Spoonbill (SVNKit-powered implementation of Flamingo’s breadcrumb bar
  • 😻 Added Meteor – Kotlin extensions for core Swing APIs
  • 😻 Added Ember – Kotlin extensions for SubstanceCortex APIs
  • 🤷‍♀️ Renamed Kormorant to Plasma
  • 🤷‍♀️ All core Kotlin modules (Ember, Meteor, Plasma) moved under the top-level kotlin-ext folder
  • 🤷‍♀️ Jitterbug (visual tool for editing Substance color schemes) renamed to Apollo
  • 😻 Added Ion – sample walkthroughs for replacing SwingWorker with Kotlin coroutines

Neon

  • 💔 An almost complete rewrite of NeonIcon APIs
  • 💔 Most Flamingo and Substance APIs moved off of ResizableIcon and to ResizableIcon.Factory
  • 💔 Moved some icon colorization APIs from Substance to Neon
  • 💔 Removed usage of UITable from FontPolicy API

Photon

  • 💔 Removed default public no-argument constructor from bundled templates for Java and Kotlin targets

Trident

  • 💔 Moved to builder-based construction of timelines

Substance

  • 😻 New Graphite Electric skin
  • 😻 New APIs for working with complex renderers, including built-in animations
  • 🤷‍♀️ Fix for incorrect offsets of rotated texts
  • 🤷‍♀️ Fix for inconsistent font metrics between preferred size and rendering passes
  • 🤷‍♀️ Fix for incorrect vertical position of icons in JOptionPane
  • 🤷‍♀️ Fix for crash in showing JColorChooser dialog
  • 💔 Moved all three Office 2007 skins to the extras pack

Flamingo

  • 💔 Moved all lower-level components (command button, command button strip. command popup menu, command button panel) to the new world based on content models, presentation models and projections
  • 😻 Added support for placing any ribbon content (including components, application menu links and galleries) in the taskbar
  • 😻 Added support for taskbar overflow (including built-in horizontal scrolling)
  • 💔 Keytips for taskbar content are controlled by keytip policy
  • 😻 Added support for separate keytips on action and secondary / popup areas of command buttons
  • 😻 Added support for global contextual menu on the ribbon
  • 🤷‍♀️ Added complete documentation

The first Radiance release focused on bringing all the different Swing open-source projects that I’ve been working on since 2005 under one roof. This release (code-named Beryl) is about making them work much better together. And it’s also about making it just a bit easier to use Flamingo components in general, and the ribbon in particular, in what one might call serious, if not even boring, business applications.

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 second Radiance release for a spin. Click here to get the instructions on how to add Radiance to your Gradle / Maven / Ivy / Leiningen / Bazel builds. And don’t forget that all of the modules require Java 9 to build and run.

Radiance 1.0.0

October 5th, 2018

It’s been a few busy months since the announcement of Project Radiance, the new umbrella brand that unifies and streamlines the way Swing developers can integrate my libraries into their projects. Some of those projects have started all the way back in 2005, and some have joined later on along the road. Over the years, they’ve been hosted on three sites (java.net, kenai.com and github.com) in three version control systems (cvs, svn, git). Approaching the 15th year mark (with a hiatus along the way), it was clear that time has come to revisit the fundamental structure of these projects and bring them into a more modern world.

At a high-level:

  • Radiance is a single project that provides a Gradle-based build that no longer relies on knowing exactly what to check out and where the dependent projects need to be located. It also uses proper third-party project dependencies to pull those at build time.
  • Starting from the very first release, Radiance provides Maven artifacts for all core libraries – Trident (animation), Substance (look-and-feel), Flamingo (components), Photon (SVG icons) and others.
  • The Kormorant sub-project is the first exploration into using Kotlin DSLs (domain-specific languages) for more declarative way of working with Swing UIs.
  • Flamingo components only support Substance look-and-feel, no longer doing awkward and unnecessary tricks to try and support core and other third-party look-and-feels.

It gives me great pleasure to announce the very first release of Radiance, appropriately tagged 1.0.0 and code-named Antimony. Lines of code is about as meaningless a metric as it goes in our part of the world, but there are a lot of lines in Radiance. Ignoring the transcoded SVG files auto-generated by Photon, Radiance has around 208K lines of Java code, 7K lines of Kotlin code and 5K lines of build scripts.

It’s been a long road to get to where Radiance is today. And there’s 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 very first Radiance release for a spin. You’ll find the prebuilt dependencies in the /drop/1.0.0 folder, and if you fancy a more proper dependency management mechanism, there’s an answer for that as well . All of them require Java 8 to build and run.

Releases 2017.H1

February 23rd, 2017

Today is the day a bunch of my long-running Swing projects get officially back to life. If you’ve missed the previous post from late last year, those of you who are still in business of writing Swing applications might be interested to take a look at the latest releases of Substance, Flamingo and Trident.

Substance is a versatile, extensible and fast look-and-feel that brings a wide variety of lovingly tailored skins, as well as quite a few behavior augmentations to Swing applications. The major themes of release 7.0 (code-named Uruguay) are support for high DPI monitors, reduction of visual noise and improved visual consistency across all core skins.

Substance 7.0 also has three new skins. The first one is Cerulean skin which was part of the Insubstantial fork that was maintained by Danno Ferrin:

The other two were added to the Graphite family. The first one is Graphite Gold that uses gold highlights on active elements:

The second is Graphite Chalk that has increased contrast on all UI elements:

Flamingo is a component suite that provides a Swing implementation of the Office 2007 ribbon container and related components. All Flamingo components have been streamlined to look well under Substance skins, including full high DPI support. Flamingo’s latest release is 5.1 code-named Jileen:

Finally, Trident is the animation library that powers all the animation in both Substance and Flamingo. As this library does not have any user-facing features that directly touch pixels, there is no new functionality in this release. Much has changed since the last time I’ve worked on Trident, and the time has come to remove built-in support for both SWT and Android. With release 1.4 (code-named Enchanted) Swing is the only UI toolkit supported out of the box.

What is next for these libraries?

As the title of this post suggests, I am planning to do two releases a year. What is on that roadmap? I’m not going to make any strong commitments, but these are the rough areas for the next few releases:

  • There once was time where I’ve hoped that other look-and-feels would adopt some of the pieces of Substance. That time is long gone, and splitting the functionality across multiple pieces is just overhead. The relevant functionality from both laf-plugin and laf-widget projects is going to be folded back into the Substance code base.
  • It is highly likely that I’m going to move Substance away from “seamless” discovery of plugins based on classloader magic. For example, if you’re using Flamingo in your application, you will need to declare an explicit plugin initialization along with setting Substance as your look-and-feel.
  • Speaking of Flamingo, I’m going to focus exclusively on how those components look and behave under Substance. Third party look-and-feels are not what they used to be. It’s just not worth my time any more.
  • Having said that, there’s much work to be done in Flamingo to provide full support for high DPI monitors. This is the place to follow that work.

So, if you still find yourself writing Swing applications, I’d love for you to give the latest release wave a try. You can find the downloads in the /drop folder of the matching Github repositories. All of them require Java 8 to build and run.

 

Over the past 6 years I’ve hosted a number of my open-source projects on Java.net. Over the last two-three years the site admins kept talking about moving the hosting forward, enhancing both the visual and the backend functionality of the site. I have no insight into the complexity of the existing infrastructure and the amount of resources available. It thus thus be foolish – and pointless – to speculate on the reasons for the glacial pace at which things are happening.

After a lot of promises, early November brought the rather hostile announcement (emphasis mine):

This is an opt-in migration – we have thousands of junk, test, and abandoned projects on the site and we intend to leave them behind.  Any project owner can request that we move their projects, and any community leader can request that we move specific projects in the community.  Any project that is not specifically requested by name via the opt-in form by November 30, 2010 will be purged when the CollabNet site goes dark.  We will be keeping tarballs of the CollabNet contents and will be able to distribute them after the site goes dark, however projects that request migration are our top priority.

Aptly named “Move it or loose it“, this is quite a threatening statement that makes not one, not two, but three direct references to the projects that will not opt-in to the migration. Even though i’ve put the development and maintenance of my projects on hold, i still want to have the sources, binaries, documentation and the source history available for interested developers. And so i promptly added all my projects to the opt-in form.

Fast forward three weeks after the deadline date. A couple of days ago a comment was left on my blog (thanks Eugene) – Substance look-and-feel is nowhere to be found. It’s no longer at substance.dev.java.net and certainly not on the new java.net/projects. Let’s look at my new profile page that lists some of the projects that i asked to migrate. Looks like java.net/projects/substance is the winner, except that it leads to an error page. Most of the project links on my profile page lead to errors, and some lead to the subset of the original content. Every page takes minutes to load, and i have no idea if the old forum postings and binaries will ever make it through. Top priority indeed.

So here’s the deal. Over the next few days i will upload all the sources, documentation and additional materials to my GitHub page. However, it will be up to you to build the binaries, run sample applications and browse the downloaded documentation. I simply don’t have time to untangle this horrible migration mess that was unilaterally forced on me and my users.

And yes, i know that Java.net was a free service, and that the same exact thing may happen to GitHub in five years. I’m not that naive.