GNOME Bugzilla – Bug 301704
List controls should use consistent row highlighting
Last modified: 2020-12-04 18:19:42 UTC
Distribution/Version: Ubuntu 5.04 Nautilus and Evolution (as well as other apps such as Synaptic) feature multi-column listboxes that use different colors in alternate rows. The goal is to make it easier to see what row a particular item belongs to. However, this technique causes two problems. 1. When there is no selection, the non-white rows look as if they are selected, especially when the number of items in the list is small (for example, 3). 2. Apps that use this technique are not only inconsistent not only with other listboxes in Gnome, they're inconsistent with themselves. (For example, Nautilus doesn't use such highlighting in its "Visible Columns" dialog, and Evolution uses different colors for alternate listbox rows in Tasks than it does in Mail.) I suggest that the problem be solved at the source: Gnome themes (including the default theme) should use some better technique of making it clear which row an item belongs to, and apply that to *all* listboxes. This probably involves a subtle border between adjacent rows: for example, pale grey rows with a 1px white solid border, or white rows with a 1px dotted grey border. Further, the HIG should be modified so that it no longer includes such alternate highlighting in its illustrations <http://developer.gnome.org/projects/gup/hig/2.0/controls-lists.html>. (Filed in gnome-themes in the absence of a "General consistency" product.)
Here's a bit of info from a technical point of view: There are two things that affect whether rules are drawn in a list/tree view: the application and the theme. The application can call gtk_tree_view_set_rules_hint() to hint that rules would be useful in a particular context. The documentation of that function reads as follows: * This function tells GTK+ that the user interface for your * application requires users to read across tree rows and associate * cells with one another. By default, GTK+ will then render the tree * with alternating row colors. Do <emphasis>not</emphasis> use it * just because you prefer the appearance of the ruled tree; that's a * question for the theme. Some themes will draw tree rows in * alternating colors even when rules are turned off, and users who * prefer that appearance all the time can choose those themes. You * should call this function only as a <emphasis>semantic</emphasis> * hint to the theme engine that your tree makes alternating colors * useful from a functional standpoint (since it has lots of columns, * generally). The theme has final say over how the widget will be displayed. The policy of most themes is simply to draw rules if the rules_hint is set, and not otherwise. If you see applications that probably shouldn't have rules (e.g. single column lists) then it would probably be best to file bug reports against those applications.
Also note that Evolution primarily uses ETable. The folder/address book/tasks/calendar tree is GtkTreeView. The message list is ETable. The list view in the address book is ETable. The Task list views also use ETable. The list view in the Calendar also seems to be an ETable. The difference in the task and calendar views is due to the need to show what calendar or task list a particular item belongs to. Rule hints are not drawn using a particular color, but rather a shaded value of the color that is set as the background. Since most themes draw the background as white, this generally happens to be a very subtle grey hint. For the Evolution calendar and tasks, it's a slightly darker shade of the selected color for the calendar or task list that the entry belongs to. I would prefer some better way to show what calendar or list an item belongs to in Evolution, but I am not sure what an easily implementable way to do that is.
Moving to GTK+ as this is really a GTK+ usability bug more than a theme bug.
As James said, this is really more of an issue with individual applications and maybe themes. Moving to HIG.
Row highlighting has been deprecated in GTK+, so closing as obsolete.