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.
You got a friend, Mike! 😀 (also had that problem… T_T )
I’m thinking of refactoring my JTextField and JTable into reusable widgets, if you’re interested.
Since, its been long, have you already JTextField and JTable into reusable widgets?
Thanks.
Yup. There’s a package called Widgets. I see, you have already checked out my initial post describing the reusable widgets (from here). Keeping the tradition with SlickerBox 😉 ) I have no actual documentation of the library, but all existing widgets have the same name as the Swing counter-part but with ProM instead of J at the beginning (e.g., ProMTextField).
Widgets typically expose the same API as their Swing counter-parts (often they even inherit from their Swing counter-parts), but the API is added on an as-needed basis, so they may be lacking functionality you need. Just let me know and I’ll add any needed functionality (unless you have commit-rights, in which case you can do so yourself).
There is a big demonstration of all available widgets and how to use them (it’s in the Widgets package or online at https://svn.win.tue.nl/repos/prom/Packages/Widgets/Trunk/tests/src-test/test/WidgetTest.java and https://svn.win.tue.nl/repos/prom/Packages/Widgets/Trunk/tests/src-test/test/TestPanel.java