Garrett and Tuomas:
Maybe there is too much icon noise. But I certainly don’t think a unilateral remove-all-button-icons approach is the best solution. Icons do have an advantage in that they are quickly recognizable once learned. I can spot a Save icon in a widget soup much faster than I could scan for the word Save.
I don’t think the best way forward is adding more rectangles with text. See, for example, our file chooser and Apple’s:
GTK+ File Open Dialog
Mac File Save Dialog
Ours looks boxy with all those icon+text buttons. And just removing the icons wouldn’t make it any less boxy. It’ll just be boxy and texty. What you’ll notice about Mac dialogs is that they’re not afraid to have icon-only buttons.
Without button icons, our Help buttons will look like KDE’s:
Apple just uses a cute ? button for Help:
(I have no idea why the callout calls it a Back button.) And Windows has a ? button in the titlebar:
Notice that the KDE dialog also had the ? button in the titlebar. We could go a long way towards being less boxy by having specialized buttons without text. See, for example, the Add/Remove button pair on the Mac:
If we had a GtkHelpButton (yeah, all right, I talk about Help buttons a lot), it could render as a stylized button with nothing but the life saver icon, maybe desaturated a little. And on Windows it could still be rendered as a regular text button with “_Help”. Better still, if window/dialog APIs have a high-level add_help sort of function, GTK+ could just use the titlebar button on Windows.
Point being, just removing button icons doesn’t make our interfaces always look better. We ought to step back and look at our designs and some of the common buttons, get some good designers (that’s you guys!) to mock up something that doesn’t fill the screen with boxes, and then figure out how to work that into our development process.
