This is Bugzilla
View Bug Activity
Format For Printing
Clone This Bug
There are no labels above columns in Trash folder.
In Find e-mail result window columns are nameless too, except of Path.
This is by design, the trash can have all different types of items in it,
having specific labels would only work for one type of item. If you have a mix
of deleted mail and contacts, what do you put as the headers?
Maybe I could hide the headers entirely...?
Empty headers looks incomplete. The best solution I can see is to change labels
in-the-run regarding of what is selected at the moment. But if you prefer not
to show labels I think title bar should be vanished too.
The problem with hiding the headers, which initially I thought was a good idea,
is that the user can no longer resize the headers to taste. I could of course
resize the columns to fit the content but that may mean that a single large
piece of text pushes all the columns off the page. I don't have a smarter
resize algorithm to throw at it right now (i.e. similar to HTML column layout).
Putting the headers relevant to the current selection would still leave the
edge case of what to do when both email and contacts are selected in the trash
I'm leaning towards leaving it the way it is.
Yeah, resizing is a good reason to keep headers visible.
In meantime I was looking around for similar circumstances in other programs.
The dominant strategy is to show as much information as is possible.
If we paint one cell in spreadsheet in blue, another in red, color tool
displays color as long as one cell is selected. When we select both, color
indicator becomes "empty". I consider this more valuable then show nothing at
Spreadsheet has another interesting feature: one cell in each selection is
"current" or "leader". There is simply the last touched one. If given action
must be made against single cell, the leader is that one. It is visually
distinguished in painted selection by additional tiny frame.
This type of selecting we can observe in Outlook Express, too. Range of
messages selected eg. with Shift+Click has always the last one distinguished
from others and this "leader" message is shown as a current message in a view
box. Similar behaviour is common among many programs.
So, my vote is: to show valid header labels when compatible items are selected,
otherwise hide labels or show them against "leader" item.
Ok that sounds reasonable but I'm going to make this a really low priority
thing compared to say actual bugs and crashes.