Kirill Grouchnikov's Blog

Look-and-feel esoterics

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?

Comments

• heh, Id guess that its not there because it doesn't do too much(at least looking at the source it seems to lack adding controls). It also forces the LAF writer to choose a chooser, though it is questionable what forcing them would gain since they are probably are going to define something else anyway.

  I suppose eventually Substance will not even be derived from the basic package but be something shiny new from the plaf package?

  leouser

  Posted by: leouser on August 16, 2006 at 04:24 PM

• I haven't seen a single third-party LAF that defines its own file chooser UI completely. Some (like Synthetica or Quaqua) add a few assorted operations on top of what exists in the super implementation and some (like Liquid and Substance in one of its earlier versions) just copy-paste the entire thing and tweak a few layout / control related stuff.
  I have no plans whatsoever to move from Basic to a complete implementation (from the scratch) - Basic has 1.9MB codebase and it's there for the reason. The only thing that perhaps i'll write from the scratch someday would be the TabbedPaneUI delegate - too much private stuff in there.

  Posted by: kirillcool on August 16, 2006 at 04:33 PM

This work is licensed under a Creative Commons License.