After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565403 - Do not bold folder when subfolder with unread messages is already expanded
Do not bold folder when subfolder with unread messages is already expanded
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
2.22.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2008-12-23 00:03 UTC by Nick Jenkins
Modified: 2021-05-19 11:08 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Nick Jenkins 2008-12-23 00:03:22 UTC
I use a deep hierarchy of mail folders for storing mail (e.g. 7 folders deep is quite common), and I usually have the tree expanded, and I usually have unread mail in a few of these deep folders, which means that all of the parent folders in the tree hierarchy become bolded in Evolution. This makes it hard to see which folders actually contain unread email. Ideally only the folders with unread mail would be bolded if the tree is expanded.

One possible suggestion: Only bold the folder in the tree view if either:
A) it contains unread mail itself (i.e. does not include subfolders), or:
B) if a child/grandchild/great-grandchild/etc folder is not visible / expanded, and it has unread mail. This should only propagate up the tree whilst the tree is not visible, and should stop when the tree becomes visible.

Result: This way, if people collapse their trees, then they can still see where the unread mail is hiding (as per current), but if people expand their trees, then it gives a very easy way to see where the unread mail is (which is not the case currently, because of the way the bolding applies to parent/grandparent/great-grandparent folders as well, which clutters up the tree view).

See also: sort of related to this is bug 214238, which wants italics (or underlining) for parent folders that have children with unread mail. That's similar, and would probably be an improvement (since "contains unread mail" and "has a descendant that contains unread mail" are differentiated), but this suggestion goes even further, as it only applies when the tree is collapsed, which is when it's needed.

Basically, if I can see the child folder, then I can already tell that it has unread mail, so there's no point in telling me all the parent folders contain a subfolder with unread mail in that case. Better to make it easier to see just those folders with unread mail.
Comment 1 Akhil Laddha 2009-08-26 06:38:35 UTC
bug 214238 fix will be available in 2.28.0. Pattern can be seen here
http://bugzilla.gnome.org/show_bug.cgi?id=214238#c12

May be worth trying again when evolution 2.28.0 comes out.
Comment 2 Milan Crha 2009-11-27 09:48:41 UTC
I'm against this, personally. I try to keep my folders all read, and because it isn't as that small then I use to see whether any folder left to read by simply looking at the top. It's just that my mail-flow is different from that yours.

I would say: if at all, then with an option.
Comment 3 Nick Jenkins 2009-12-03 05:09:13 UTC
Re comment #2:
Understood, it's different usage patterns: I keep my folders expanded, and some of those folders contain items that I need to come back to later, or am waiting on other people for (so I usually keep them unread in the interim) and then this unread state propagates up the tree, cluttering it up. But I agree it's just a different workflow, and an option would be ideal if the current behavior is beneficial to some users.
Comment 4 Matthew Barnes 2009-12-03 05:51:05 UTC
Thunderbird, I think, has hit on a good idea with its unread folders view.  Might be worth adapting that to Evolution in some form.  The other folder views I'm not so sure of.
Comment 5 André Klapper 2021-05-19 11:08:24 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/evolution/-/issues/

Thank you for your understanding and your help.