Kirill Grouchnikov's Blog

August 2006 Archives

SVG and Java UIs part 2: SVG file explorer with resizable previewer

This entry outlined the importance of scalable icons for the next-generation UIs and showed how SVG format can be used to achieve resolution-independent easily scalable icons. One thing that i haven't been able to find is a SVG file viewer / explorer that shows all SVG files in the current folder and allows scaling them. Inkscape file chooser provides the preview, but it's only for the selected image and it's not resizable. So, instead of looking further on the web, i decided to implement such viewer on top of the existing components in the flamingo components.

The SVG file explorer reuses two existing components. The first is the breadcrumb bar which was contributed to this project by Topologi. You can read how this component can be used to create a Vista-style file explorer right here. Another component is a ribbon button from the ribbon component that uses a resizable icon and two-line optional label (which is used to show the filename). After about two hours of work of putting this together (interrupted by spectaculously boring season premiere of "Bones"), here are some screenshots of the SVG file explorer in action. Note the breadcrumb bar file path selector on top.

The first image shows all folder SVG files in 32*32:

The second image shows all folder SVG files in 48*48:

The third image shows all folder SVG files in 80*80:

The last image shows all folder SVG files in 128*128:

Unfortunately, due to some issues with the underlying SVG renderer i can not provide a signed WebStart application. This issues have been reported on the relevant project tracker - you're welcome to vote on them.

Undoubtedly, for application like this, the Apache Batik renderer Swing components are a better choice, since they offload the SVG loading to a worker thread. Stay tuned for Batik integration.

SVG and Java UIs part 1: SVG-based resizable icons for next-generation UIs

The high-resolution LCD and plasma monitors are quickly becoming an affordable commodity, and the next versions of two major OSes (Vista and Leopard) will be using vector-based continuously-scalable icons and UI elements to create UIs that easily scale on 120+ DPI monitors. One of the vector-based formats quickly gaining popularity is SVG.

One of the flagship Microsoft's applications was and remains Office. Office 2007 introduces a new UI concept called ribbon which makes very heavy usage of scalable graphics to convery the same amount of information on different monitor sizes and application resizing. You can either read through Jensen's blog or find a short version right here. Giving the user the ability to scale the UI to his / her taste will be an invaluable feature, but it comes at a price for us, the developers. See this entry on Geertjan's blog to see the wrong way to scale icons.

This entry from about a year ago showed how to utilize Java2D to create scalable icons. However, this requires considerable design talent and time investment. What if you're short on one of them? SVG comes to the rescue. With continuous additions to the Tango project (thanks to Kohsuke for mentioning this project on his blog a few months back), and open-source libraries such as Apache Batik toolkit, the icon scalability can be easily achieved in modern Java UIs. The test application that comes with the flamingo components (see WebStart link at the end) uses the SVG Salamander renderer to turn SVG files into scalable icons. The choice between Batik and SVG Salamander in this particular case was in favor of the later, since it is much smaller and has less steep learning curve (although it has quite a few problems in rendering some of the Tango images).

Here are a few screenshots of the Ribbon UI under different application sizes. All the screenshots feature the same highlighted button, to that you will be able to see the same icon rendered in different sizes. The first image shows the UI when all the buttons are rendered at full size:

The second image shows the UI when some of the less important buttons use smaller icons but still show the labels:

The third image shows the UI when all buttons use smaller icons only due to the lack of screen space:

The final image shows the UI under extremely small width, where the entire band has been collapsed to a single button, which (when clicked) shows the original full-size buttons in a popup window:

Note that SVG supports transparency and translucency, allowing the icons to blend with different color backgrounds (note the circular shadow beneath the clock and the fuzzy yellow thingies in the top corners). Here are some screenshots of the same band under different color schemes (using Substance skins described here):

To launch the test application, click on the image below. You can play with the icon sizes by resizing the window. You can play with various themes / watermarks by going to the "Look & Feel" task.

Naming project releases

I don't know about you, but i was saddened by the decision to drop internal names for JDK 6.0 and 7.0. Some time ago i even speculated on the possible names for 8.0 (which sparked quite a lively discussion on TSS). It could've been nice to have correctly predicted a name in advance...

Which brings me to the main topic - giving internal names for releases is fun. Especially when you get to choose the name. Last year one of my colleagues (long time no see, Yaniv) has objected to using internal names because they don't convey the release sequence. With numbering you know that 9.0 comes after 8.5.3 that comes after 8.4. But with names such as Cheetah, Puma, Jaguar or Leopard, there is no real way for an outsider to know the sequence. But it doesn't have to be this way...

The first Substance release to have an internal name (which is pretty funny definition, since i'm the only developer, so it's between me, myself and the guy i have to see every morning in the mirror) was the release 2.0. I decided to code-name it Dakota since it's a nice, short and not complicated name (unlike some of the names picked for JXTA. Come on guys, do you seriously expect people to use it?) When the time came for the next release and i started looking for a name, i remembered what Yaniv told me and then i suddenly realized (OK, too much second-hand watching the "Sex and the City" which is the must-see of my lovely wife) - Dakota starts with the fourth letter in English alphabet, and release 2.0 was the fourth release (after 1.0, 1.1 and 1.2). And so the dynasty was born :)

The next releases were named El Paso, Firenze, Grenada and Honolulu with Iowa, Japan and Kentucky planned in the future. This way, the releases are named consistently (geographic places i've never been to... Damn, i was in Firenze :), but still preserving the release sequence. For flamingo components i use Irish female names, with Aoife and Briana for existing versions and Caireann, Deirdre and Eilinora planned for the future (i know, JXTA guys, they're quite a mouthful as well). For laf-widget layer i use flower names, with Amaranth and Bluebottle for existing releases and Camellia, Daffodil and Eglantine planned for the future.

So, how do you choose the internal names for your releases?

Skinning your Swing apps

• Active theme - for controls in active visual state
• Default theme - for controls in default visual state
• Disabled theme - for controls in disabled visual state
• Active title pane theme - for title panes of active windows

  /**
   * Creates a new complex theme.
   * 
   * @param displayName
   *            Theme display name.
   * @param themeKind
   *            Theme kind.
   * @param activeTheme
   *            Active theme.
   * @param defaultTheme
   *            Default theme.
   * @param disabledTheme
   *            Disabled theme.
   * @param activeTitlePaneTheme
   *            Active title pane theme.
   */
  public SubstanceComplexTheme(String displayName, ThemeKind themeKind,
      SubstanceTheme activeTheme, SubstanceTheme defaultTheme,
      SubstanceTheme disabledTheme, SubstanceTheme activeTitlePaneTheme)

Example of a complex theme:

Note that the basic themes of the complex themes are not necessarily simple. This creates the following visual theme (featured in the matrix rain screensaver which now has proper WebStart version):

Another example of a complex theme:

which creates the following theme:

Here are few more examples of complex themes:

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?

This work is licensed under a Creative Commons License.