Comboboxes in Substance 6.0 – feedback from Matt Nathan

October 28th, 2009 | 7 Comments »

I believe there are two kinds of feedback – one of them is useful, and another is not. It’s quite easy to differentiate between two – the useful feedback is a detailed list of actionable items, while the useless feedback is talking in generic terms such as “wasn’t happy with it” or “it hurts my eyes”. To put it frankly, there’s not much that you can get from these brush-off remarks, nothing you can learn and nothing you can act on to improve your library. On the other hand, when you get a thoughtful and meticulous list of specific items, you may or may not agree with some of them, but at least you have a very good direction to explore.

I consider Romain Guy’s feedback in September 2006 to be a turning point for Substance look-and-feel library – this was the point when i stopped being obsessed with what can i do with Java2D, and started being more concerned about UI consistency and elegance. The work in Substance is far from being done, and over the past few days i have been reworking the visuals of text components, combo boxes and spinners. My previous entry on this subject has brought an excellent feedback from Matt Nathan (and this is not the first time it has happened), and here i want to address each one of his points.

All of the points in his comment can be seen in the following screenshot:

Point #1: the inner border line (the dark one) of the top left corner of the lighter themes editable combo boxes looks like it’s cut off slightly.

Let’s take a closer look:

Here, the top-left corner of the inner border is painted over by the opaque editor text field – which is an internal implementation detail. This has been fixed and now looks like this:

Point #2: the roundedness of the non-editable and editable versions is different, not sure if this is intentional but I prefer the editable version.

Right now this is as designed. An editable combobox is designed to look exactly like a text field (with an embedded arrow button). As such, it has the same exact corner radius – which in the current implementation is twice that of a regular button. And since uneditable comboboxes are designed to look exactly like buttons – you have the difference in corner radius. I will experiment with different radiuses in the next few days.

Point #3: the look of the hovered editable combo box’s button looks like it has a little ridge between the button and text field that doesn’t really fit with the rest of the look.

Let’s take a closer look:

The lighter outer line on the left edge is coming from the code that is using the same border appearance for the button as it does for the entire combobox. However, it shouldn’t be here, since it just creates unnecessary visual noise. This has been fixed and now looks like this:

Point #4: the down arrows of the editable combo box doesn’t line up with the down arrow of the other states, it’s closer to the right edge than the others.

Let’s take a closer look:

Here, the internal implementation details are causing the incorrect arrow alignment. Internally, the uneditable comboboxes do not show the arrow button at all. Instead, i’m just painting the arrow icon positioning it based on the current font size of the combobox. However, the arrow icon on the editable combobox is part of the arrow button, and the button insets / bounds did not match the settings for the uneditable comboboxes. This has been fixed and now looks like this:

Point #5: the baseline of all the buttons (and the text fields from your last blog) seems to be a pixel or two too low. This could just be me but they look off center vertically, though I’m sure they are central programatically (it looks like you’re centering on the font ascent or font height without taking descent into account)

This is actually as designed. The number of pixels from the top border to the ascender line is the same as the number of pixels from the bottom border to the baseline – and not the descender. This is exactly the same as in Vista and Snow Leopard, and highly unlikely to change in the immediate future.

Once again, many thanks to Matt for his time and attention to details. I can only hope that I will only get the useful feedbacks in the future :)

---

Related posts:

1. Comboboxes in Substance 6.0 One of the items on the roadmap for version 6.0 of Substance look-and-feel (code-named Sonoma)...
2. SVN Breadcrumb Bar – feedback from the comments Following the comments from the previous entry that introduced a Swing breadcrumb bar component that...
3. Control alignment in Substance 6.0 Last week i have written about improving the visuals of text components, comboboxes and spinners...
4. Substance 5.2 – extended support for very large fonts Supporting wide variety of font sizes in modern UI toolkits is a necessity, and previous...

---