If i had to put a number on it, i would say that more than 90% of the feedback that i receive on my projects is on bad behavior (exceptions, visual artifacts, broken APIs etc). I don’t complain. Not only this person decided to download and evaluate one of my projects. He also decided to spend his time to report the problem he is seeing via the project forums, mailing lists or a private e-mail. I’ve said it before and i’ll say it again – a feature that has absolutely no feedback is a feature that nobody is using.
In fact, as a developer myself i don’t even expect the “thank you” e-mails (and this post is most certainly not a solicitation for one). However, i would like to use this space as a collective “thank you” to all the open-source libraries that i am using and the people behind them. Please know that when you don’t hear from me, it only means that your library is working as expected. Thanks for all your free time and countless hours spent working on your projects. Thanks for spending this time away from your other hobbies, and sometimes even away from your family. It is much appreciated by your users. It is much appreciated by the community in general, even when we decide to go with a competing solution. Having choice is good for us as users, but it is also good for you as developers.
I would also like to thank the developers of the core engine itself. The work that you do on the JDK is seen by millions of people and even when we complain, it is all in good spirit. Do not be discouraged when you make a great new feature and all people seem to focus on is one specific bug that is still unfixed in the core. It is in our nature to exaggerate and focus on the negative, but this does not mean that we do not appreciate the work that you are doing.
And finally, i would like to thank developers working on new projects and exploring new frontiers. Keep up the work and don’t get discouraged by the level of attention from the outside community. Good ideas take some time to settle in and win developers’ hearts.
With release 4.3 of Substance look-and-feel available last Monday (and a few patch releases to address bugs since then), it is time to think about the next release. Substance is now three years old and it has seen fourteen releases since it was started in April of 2005. Most of the minor releases did not introduce binary incompatibilities, and the last two major releases (3.0 and 4.0) touched the public APIs in ways that should have affected only a small portion of users. However, due to my very heavy commitment to make Substance the library of choice to create modern user interfaces (and resulting short release cycles), sometimes i have made bad decisions on the features to include and the APIs to expose them.
Over the last year and a half the Substance codebase has become a complex thing to understand and maintain. Every new feature that has been added (especially the skins and decoration areas) made it ever more difficult to maintain backwards compatibility and still address the needs of designing modern UIs. This sometimes led to an awkward implementation and even more awkward public APIs (as anyone who dared to use a SubstanceComplexTheme would attest).
Even though i am the single developer on the project (but thanks to all those who sent bug fixes and graciously contributed portions of code), i found it increasingly harder to understand and extend existing functionality. And here i am not talking about working on the project every other weekend; i look at and work with the code pretty much every day. Something had to be done, and over the last eight months i have considered the two options that i had.
The first option would be to start a new project. Learn from all the mistakes that i’ve made, all the features that were added and not used, all the accidental complexities that grew exponentially and didn’t really mesh well together, all the nice-to-haves that added performance hit even when not used. In short, stop working on Substance (moving into maintenance bug-fix mode only) and start anew.
The second option would be to wait for the next major release and do all the things necessary for the long term health and viability of the project. To rework the cruft and the mess into an API that best reflects my understanding of creating modern UIs as i see it at this moment. To put myself into my users’ shoes and question every client property, VM flag and API method. To see how hard it is to customize the default behavior without reading the Javadocs and the documentation. To see how hard it is to create a custom skin after reading the source code of existing core skins. And most of all, to see what can be sacrificed in the short term to address the long-term problems.
The first drop of the next major release (code-named Substance 5) will be available for download tomorrow. Here is the list of major changes that have been made to the core library and its plugins.
- Requires JDK 6.0. The only VM that is being used for tests is 6u10.
- SubstanceLookAndFeel class is now abstract and does not have any public constructors. Use a core skin-based LAF, extend to set a custom skin or use static setSkin method.
- Removed support for pluggable text rasterizers (substance-bramble plugin based on SWT). 6u10 addresses poor Segoe UI rendering on Vista.
- Addressing performance. The first drop of 5.0 is 20% faster than release 4.3. This is work in progress.
- Reworked notion of themes. Split the functionality of SubstanceTheme, SubstanceComplexTheme and SubstanceSkin into SubstanceColorScheme, SubstanceColorSchemeBundle and SubstanceSkin. Tweaked most of the core skins to take advantage of the new more flexible and straighforward APIs.
- Removed most of the VM flags. The only two flags are for tracing memory allocation and heap status. Use skin / image watermark / configuration APIs.
- Reconciled APIs that were added to address specific user requests and did not result in a consistent API. This should make making a custom skin / tweaking default Substance behavior easier and more straightforward.
- New client property to provide per-window skinning. Can use different skins for different top-level windows.
- Removed the client properties and APIs for setting themes and painters on per-component level. Use colorization client property and per-window skins for custom tweaking.
- The new default mode does not add any extra UI elements (menu search, lock icons etc).
- Removed performance-adverse functionality of custom overlay and composites. Was unintentionally broken since release 4.2 and intentionally unfixed in both 4.2 and 4.3. A single complaint shows that this functionality is of minuscule use.
- Removed combobox auto-completion. Use SwingX, GlazedLists or JIDE.
- Moved UI debug mode (additional context menu on title panes and scroll bars) to a substance-tools plugin
- Consolidated existing theme pack, button shaper pack and watermark pack into substance-extras plugin
- New SubstanceApi annotation marks public APIs (classes, constructors, methods)
- Internal restructuring of the packages to make the codebase more organized.
Undoubtedly, the most important bullet in this list is moving to JDK 6.0 as the runtime requirement. This has not been a minor decision. I understand that for a great number of users this will mean that they will not upgrade to Substance 5. I am doing this for the long-term health of the project.
At this point, release 4.3 officially enters into the longterm bugfix mode. With older releases i only backported bug fixes during the first week after a stable release. Release 4.3 will continue to receive all but most complicated bug fixes to accommodate users that can not upgrade to Substance 5 (due to JDK requirements).
For more information on changes to the client properties, VM flags and APIs consult the first draft version of the API change overview document. The project documentation will be updated in the following weeks.
Here are some Swing links that you might have missed during this week:
- Sandip Chitale has two tips on using JOptionPane component. The first tip show how to use multiline text and images, and the second tip is on making the component dialog resizable.
- David Qiao has announced the official release 2.0 of JIDE Desktop Application Framework.
- Maxim Zakharenkov has announced release 1.0 of the Swing Explorer project. The getting started guide shows the potential of this project for visual debugging of Swing application. The player feature looks particularly impressive.
- Nazmul Idris sums up the limitations of the current native font rasterizer in 6u10 latest builds.
- Geertjan Wielenga writes an overview article on FEST-Swing project by Alex Ruiz and Yvonne Price.
- Roman Kennke posts updates on the Caciocavallo project. The first is on build errors, and the second is on font rasterization.
- Fabien sums up a few libraries and tools that help building Swing applications.
- And finally, the Glimmer project proposal has been accepted by Eclipse. The goal of this project is to wrap SWT with a JRuby DSL for easier authoring of cross-platform user interfaces. While interesting on itself, this might also prove a good catalyst and inject some life into the Swing-based efforts in Groovy, JRuby and Scala.
It gives me great pleasure to announce the official release for version 4.3 of Substance look-and-feel (code-named Nairobi). The list of new features includes:
It was on this day in 2005 that Substance project has been created. It is now three years old and to celebrate this occasion i have redesigned the main project page to be less cluttered and a little better organized. Hope that you like it, and if you have any comments, i will be more than interested to hear your opinion.
A few screenshots of the new functionality in Substance 4.3:
New decoration painters applied to the Flamingo ribbon component:
Highlight painters on table (note a single-line border separators):
Colorized visuals of disabled selected buttons:
A button with 72 pixel font:
Click on the button below to launch a signed WebStart application that shows the available Substance features.
The sources and binaries are available on
the project site and the CVS repository.
