© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Currently we are using a hard-coded graphic that looks like a Human button, because GTK apparently does not yet allow buttons inside treeview cells. (This is why you don't get the proper mousedown feedback when clicking the button.)
Even so, we could used the stock Human arrow icon inside this hard-coded graphic. Why didn't we? A minor reason is that the stock icon is colored (as shown in the mockup), and that would look more obviously wrong when you were using any theme other than Human. But a more important reason is that it would be less visible than a black arrow, and therefore inappropriate for the purpose. Like many of the stock icons, the stock arrow icons make much more sense in large toolbar buttons than they do in confined spaces like this. For two more examples of this problem, see the Store's search field (as also shown in David's mockup): using a search icon and a clear icon that were both meant for toolbar use looks quite lame inside a text field where everything should be much more symbolic (like the double-arrow graphic to indicate an openable menu, or the checkmark on a checkbox).
So, I think there are five steps to fixing this bug:
1. In GTK, implement the ability to include real buttons inside treeview cells. (This would also allow the use of real Play buttons in <http://
2. In the XDG icon naming specification, add a -symbolic variant to the standard arrow icons -- and also to the search, clear, volume, network, battery, and other icons that typically appear in the panel (because many people have a desire for such omnipresent icons to be simple and monochrome too). Thanks to the clever hierarchical system of the naming spec, themes that don't have the symbolic icons will fall back to the non-symbolic versions. This will seem off-topic, but it's important to do at the same time: In the specification, state that any -symbolic icon should be drawn almost entirely in a defined color (perhaps #ff00ff) that is unlikely to be used in real icons, and that they should use any other colors sparingly. Then, the GTK code that renders the icons can render that specified color in a way requested by the application, while leaving other colors alone. For example, if you have a pale green panel with dark green text, the battery-low icon can be rendered in mostly the same dark green as the panel text, but the battery level itself will still be red. Another example: Chromium would then be able to use the symbolic variants for its toolbar, with a dark blue tint if it insists, so that it uses fewer custom icons.
3. Implement the code in GTK that specially handles the color for -symbolic icons.
4. In Human and other themes that matter, add new monochrome icons for the -symbolic names.
5. Change the Store code to use a real button containing the symbolic arrow icon.