135092 - Parent folder should show count of unread including all childrens, when not expanded

Status: RESOLVED DUPLICATE of bug 235956

(MailNews Core :: Backend, enhancement)

Description

[Toms Baugis]

I mean this way:

>Project (10)

when expanded, then
Project (5)
|- ModuleX (3)
|- ModuleY (2)

..or something - it could be nice!
(i could see, when i have mail in these folders)
(i filter mail directly to moduleX and moduleY)

thanx for your job! i just luv mozilla!

tm

Comment 1

[Håkan Waara]

Good idea.  How are we currently doing?

Comment 2

[Juxi Leitner]

I support that too!!
It would also makes it easier for the ones using WinXP (where you see your
mailbox count at the login screen!) when you see the full (with children) unread
message count!

Comment 3

[Vidar Haarr (not reading bugmail)]

Håkan: The current behavior is just to make the collapsed folder 'bold' if it
contains unread messages. There is no telling how many it contains.

I want this :)

Comment 4

[Joey Day]

An additional idea would be to have the folders auto-expand (a la Outlook
Express) to show when a new message arrives and is filtered into a sub-folder.
This would, of course, be a user setting.

At any rate, a count of emails in folders/sub-folders is a much needed feature.

Comment 5

[[e-mail]]

*** Bug 192574 has been marked as a duplicate of this bug. ***

Comment 6

[kaeptn00]

I'd like to put a HIGHLY WANTED tag on this one. I use a couple of accounts and
it annoys me to swtich all folders open to find out where the message has been
sorted to. sometimes only to find out it was a message in a folder I currently
just don't  want to know about ;)

In summary: The amount of unread messages should be visible in the top most
hierarchy above the folder containing the unread message. The counter should/may
disappear if the hierarchy is openend to make UI more readable.

Comment 7

[Toms Baugis]

looking on evolution and rethinking the whole thing - i think, that setting the
parent folder to bold also would be enough (changing numbers, depending on tree
state would be against user interface)

Comment 8

[Sergio Del Franco]

Suggestions:
Add an "Unread in tree" column
------------------------------
ProjectA        |  2|  7
|- ModuleX      |  3|
|- ModuleY      |  0|  4
   |- FunctionM |  2|
   |- FunctionN |  2|
------------------------------

-or-

Show that number in brackets as netscape 4 do
---------------------------------------------
ProjectA        |  2 (7)
|- ModuleX      |      3
|- ModuleY      |    (4)
   |- FunctionM |      2
   |- FunctionN |      2
---------------------------------------------

Comment 9

[Lyle Greg Lisle]

Using Bold does not work for top level folders, they are always bold.  Some
other method is needed, and a count provides more information,

re #7, I'm unclear as to why this would "be against user interface"

I do see that it gets a little tricky determining what number to use when the
folder is open.  Do you still use the total, or do you only display what is in
the root?

Comment 10

[Toms Baugis]

i think that solution in comment 8 would do the job.
regarding my comment 7 - it is not intuitive, that numbers change depending on
tree state - only thing that should change is tree state itself.
imagine this:

Inbox (14) [+]

then you click on [+] and get
Inbox (0) [-]

it would be strange - user would then ask - "where my 14 mails have gone? (user
clicks on tree collapse again) oh - here they are! umm wait, no, i can't see
them. oh, it's total count of all subfolders, mhmhmhhmm... i don't get it, why
do they make simple things complicated" :)

Comment 11

[Lyle Greg Lisle]

Toms,
  Ah! Gotcha. It would bother the unsophisticated user.

If solution 8 is too much of a problem, perhaps just a flag on the top level
would do, but some indicator is needed.  I got in trouble recently because I
"didn't answer my mail." Unfortunately it was hidden.  :-(

OTOH, as things are now, one needs to leave every tree fully expanded to avoid
missing something.  Much clutter, and it destroys the purpose of the tree.

Comment 13

[WBT]

This may be a duplicate of Bug 235956 (technically duplicated by that bug, but that one got 'fixed').  
It appears the request made here was granted at least by version 31.  
I'm marking it fixed; if someone thinks that's incorrect please reopen.