By October 8, 2010 5 Comments Read More →

Playing With/Suffering SlickerBox

This post has 418 words. Reading it will take approximately 2 minutes.

GD Star Rating

In ProM we use SlickerBox, a library providing a pretty neat skinning of Swing. Unfortunately, SlickerBox is very time-consuming and difficult to use if you go beyond the (very few) supported widgets.

I wanted to set up a preferences pane for the new operational support service, and for shit and giggles decided to actually make it blend in.  Parts were very easy: setting up a nice tabbed pane is easy, adding label is doable, and adding check-boxes is easy. Some parts were not so easy, though; the problem is two-fold: there are no default components for arranging components, only a generic component that must be customized for each use and only some widgets are SlickerBoxified.

I therefore had to manually set up the colors of components, stealing colors from another component.  I could just have set them all to a bright pink, as making the UI consistent was actually more work than making it inconsistent.

Second, I had to customize some widgets.  For most components this corresponds to setting the opaque property to false, but for some (I’m looking at you, scroll panes) I had to not only set the opacity, but also install custom UI delegate.  A helper class promises to do this, but does so in a way that is inconsistent with large parts of the UI (as it is only used somewhere), and the helper class can only customize some components (again without any semantical hints).

Finally, I had to write some widgets myself, as SlickerBox does not come with a JTextField replacement, and just setting the colors does not make it blend in nicely.

After all of this, I arrived at this UI, which I think is okay, including both look and feel:

This took me around 4 hours to get up and running (from a working but uglier UI) and bloated my code to around 450 lines (just for the UI and excluding the 40 lines widget I needed to write). Furthermore, the code contains a bunch of hard-coded color constants and sizes, making it very difficult to alter the UI should ProM decide to change color scheme in the future. SlickerBox should really have used the pluggable look-and-feel API of Java instead of making a “light-weight” solution, which at first glance is easier and perhaps also more elegant, but which bloats the client code and is very difficult to use as soon as you get out of the (very tiny) supported domain.

Playing With/Suffering SlickerBox, 5.0 out of 5 based on 1 rating
Posted in: Uncategorized

5 Comments on "Playing With/Suffering SlickerBox"

Trackback | Comments RSS Feed

  1. Arya says:
    GD Star Rating

    You got a friend, Mike! 😀 (also had that problem… T_T )

  2. M.RAvi says:
    GD Star Rating

    Since, its been long, have you already JTextField and JTable into reusable widgets?


Post a Comment