There hasn’t been a lot of new content on this blog over the past three weeks, and this entry is just to keep you in sync with what you can expect from the next development drop of the Flamingo component suite.
Here is a partial screenshot of the controls (ribbon, buttons and galleries) under the Metal / Ocean look and feel:
Here is the same component under Windows look and feel in Vista:
And under the Windows Classic look and feel:
What about Nimbus? Here it is:
What about the Looks family? Here it is under Looks Plastic XP:
And how about Synthetica? Here it is under Synthetica Blue Ice
and Synthetica Mauve Metallic:
And here it is under Pagosoft look and feel:
And here it is under Squareness look and feel:
OK, i can go on and on with the screenshots, but you get the point. It can run under any core or third party look-and-feel without any special tricks in the application code and without writing any LAF-specific rendering. Stay tuned for more over the next few days.
It gives me great pleasure to announce the official release for version 4.1 of Substance look-and-feel (code-named Lima). The list of new features includes:
Applications that use or implement custom border painters and title painters should consult the instructions in the migration guide.
In addition to the core release, the following Substance plugins and modules have been updated as well:
The documentation has been updated with the latest visuals and APIs. In addition, there are new tutorials on Substance painters and skinning of custom components.
Special thanks for bug reporting and testing go to Mikael Grev, Vincent Trussart, Kamil Paral, Klaus Rheinwald and Jean-Francois Poilpret.
A few screenshots of the new functionality in Substance 4.1:
The inner border painters and tab pane content borders in the Raven Graphite Glass skin:
The new Creme Coffee skin:
Full support for desktop resolution settings:
Automatic font policy for Gnome desktops:
Here are some Swing links that you might have missed during this week:
- John Zukowski provides an overview of using system tray in JDK 6.0. Judged by the comments, people do not know that you can use JPopupMenu on the system tray icon.
- Alex Potochkin adds yet another useful tool to his SwingHelper project. This entry introduces a “visual debugger” painter that allows seeing what is repainted at runtime, and whether your application / custom components are repainting more than necessary.
- Patrick Lightbody is having some problems with Swing applications (namely IntelliJ IDEA) under Leopard Spaces.
- Daniel Spiewak has written an overview article on Fuse project that allows injecting external resources into custom Swing / Java2D painting code. Based on comments from Daniel and Romain, i am still not convinced that this approach is easier than writing a custom theme for an existing look-and-feel, at least for a big UI that needs consistency for all the visual elements.
- Rafael Alvarez writes about yet another Swing layout manager. You can also read the manual that has more information on the syntax and the usage of the XMLGridLayout. The goal of this layout manager is “to provide all the power of GridBagLayout with the simplicity of an HTML table“.
- Charles Tai has announced the new SwingRCP project. The goal of this project is to provide “a platform for developing applications based on the Eclipse Rich Client Platform (RCP).” This is a commercial product, and it remains to be seen whether it will be able to win the mindshares of either Swing or Eclipse RCP developers.
- An interesting RFE has made its way into the latest binary build of Mustang Update N. RFE 6604856 provides a way to define a RepaintManager for the hierarchy of specified component. I have already discussed the good and the bad sides of RepaintManager as a tool for custom painting, and one of the biggest disadvantages is that RepaintManager is a global resource. It’s not immediately clear where this functionality will be used. My hope is that it was added for internal use in JavaFX (why wait until now? this limitation has been known for a very long time), and not for yet another JavaOne demo. A look at the sources reveals that the implementation is most probably in the new internal com.sun.java.swing.SwingUtilities3 class and its static setDelegateRepaintManager class. Hopefully, this will be formally exposed in Mustang Dolphin to allow using multiple repaint managers in a supported way.
As i was looking through the folder structure of the latest Mustang Update N, a thought occurred to me to look inside the rt.jar. There are some interesting things there, and this entry will look at the class names of Nimbus look and feel.
The Nimbus classes are located in the sun.swing.plaf.nimbus package, and as Jasper already mentioned, most of the code is generated from a designer tool. While the source code of Update N is not yet available, you can still see some quirks of the auto-generated code. Let’s run a simple utility that prints out the top ten list of JRE classes with the longest names:
92:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
91:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState
91:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState
89:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState
88:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState
78:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter
77:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter
75:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter
74:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter
61:java_beans_beancontext_BeanContextSupport_PersistenceDelegate
Restricting this list to public classes only (classes with public modifier, which can still be in internal sun packages), we get
78:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter
77:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter
75:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter
74:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter
53:OptionPaneOptionPaneMessageAreaOptionPaneLabelPainter
45:MemberSubmissionAddressingWSDLParserExtension
40:ContentHandlerAlreadyRegisteredException
40:SQLIntegrityConstraintViolationException
40:SocketFactoryContactInfoListIteratorImpl
39:SpinnerSpinnerFormattedTextFieldPainter
Obviously, the class name length has nothing to do with the functionality itself. It just shows how easy it is to overlook something when you’re auto-generating code.
Going a little back to Mustang update 2, the first list looks like this:
61:java_beans_beancontext_BeanContextSupport_PersistenceDelegate
59:javax_swing_tree_DefaultMutableTreeNode_PersistenceDelegate
52:javax_swing_DefaultComboBoxModel_PersistenceDelegate
50:javax_swing_border_MatteBorder_PersistenceDelegate
48:java_util_AbstractCollection_PersistenceDelegate
48:javax_swing_DefaultListModel_PersistenceDelegate
47:UnsafeQualifiedStaticCharacterFieldAccessorImpl
47:java_awt_GridBagConstraints_PersistenceDelegate
47:java_awt_font_TextAttribute_PersistenceDelegate
46:javax_swing_ToolTipManager_PersistenceDelegate
and the second list looks like this
40:ContentHandlerAlreadyRegisteredException
40:SQLIntegrityConstraintViolationException
40:SocketFactoryContactInfoListIteratorImpl
38:DOM2DTMdefaultNamespaceDeclarationNode
38:FormatFlagsConversionMismatchException
38:TaggedProfileTemplateFactoryFinderImpl
37:Canonicalizer20010315ExclOmitComments
37:Canonicalizer20010315ExclWithComments
37:IEEE754FloatingPointEncodingAlgorithm
37:RelationServiceNotRegisteredException
So, what is your best example of the longest Java class name that you have ever seen? Can anybody beat 92 characters? .NET comes quite close with 86 characters :)
