Skip to main content

Look-and-feel esoterics

Posted by kirillcool on August 16, 2006 at 3:15 PM PDT

One of the first major overhauls i did for the next version of Substance was to ditch the inheritance from Metal and make all the delegates (and the main class itself) extend the Basic delegates. The main reason for this transition is the unnecessary overhead of Metal (parent) instantiation since Substance overrides pretty much every painting part for all components. thankfully, the painting hooks are specified in the Basic classes, so all @Override directives still hold. However, one major "glitch" in the Basic layer is the support for the FileChooserUI.

At first, launching the file chooser produced exceptions under Substance extending the Basic instead of Metal. After a little code digging, it appears that the initClassDefaults in BasicLookAndFeel doesn't set any entry at all for FileChooserUI ID. On the other hand, there is nothing in the BasicFileChooserUI that says that it can't be used directly - it's not abstract, and the Javadoc comments say nothing on the subject.

The second step was to simply put the BasicFileChooserUI into the UIManager table. This produced another exception, since BasicFileChooserUI doesn't define a static createUI method.

The next step was downloading and reading sources for other third-party look-and-feels that extend Basic. Liquid simply copy-pasted the entire implementation of MetalFileChooserUI, which has several disadvantages - first, you are facing potential licensing issues, and second, your jar grows unnecessarily. Although Alloy is closed source, it wasn't hard to see what it's doing - it doesn't have any delegate named *FileChooserUI, and the UIManager contains the MetalFileChooserUI string after setting Alloy as the look-and-feel. Apparently, Alloy initialization just sets MetalFileChooserUI as the delegate. The other two, Napkin and Skin define their own UI delegates that extend MetalFileChooserUI and provide custom logic for computing the file icons (Skin uses native icons for JDK 1.4+).

This is rather disappointing - even though you don't want Metal, you're still stuck with one of its delegates? Apparently, there's no other way - when i extended the BasicFileChooserUI (for native file icons), i got empty file chooser dialog. Once the inheritance has been done from MetalFileChooserUI, the file chooser was created normally.

So, the main question is - what's the deal with BasicFileChooserUI, and why do we need to be stuck with Metal after all?

Related Topics >>