doesn't happen here. IMAP, POP?

or... XGL/compiz? :-)

Created attachment 71605 [details]
Screenshot of the problem

Hi,

I'm not using XGL / Compiz.  Just plain ol' metacity.  Using Ubuntu Edgy (GNOME 2.15.92).

The account is a POP account.

The screenshot above demonstrates the problem.  The "Inbox" and "Gnome" folders are boldened, but the mail in the Unread Mail Folder has been read.  If I move my mouse over these folders, the bold disappears, or if I click on the "Inbox" folder, it disappears as well.

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

Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/60050

Not sure if its related, but I'm seeing the same behavior in Drivel ("Currently Playing Music" option doesn't update to new songs until mouse is passed over the entry).  Maybe its a gtk+ problem?  

Created attachment 75847 [details] [review]
Proposed fix

Bug #354633 is a duplicate of this.  The problem is unrelated to Drivel or GTK+.

On view level, the folder tree view establishes the relation to display the name in bold if the folder contains unread messages or children with unread messages.  The patch adds a handler for the row-changed signal of the model that emits row-changed for all parent rows, to update the corresponding cells correctly.

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

Actually, I wrote the thing in Drivel, that's more what we'd call a dirty hack (because you can't update a GtkComboBox when it is popped open, as far as I know, and we can't get async updates).

Confirmed.  This is pretty easy to reproduce.

Choose a nested folder with no unread messages (say, "Child Folder").

    Parent Folder
       Child Folder

Mark one of the messages in "Child Folder" as unread, but thereafter DO NOT MOVE THE MOUSE.  You'll see (CAPS indicate bold):

    Parent Folder
       CHILD FOLDER (1)

Now move the mouse over "Parent Folder".  It'll change to:

    PARENT FOLDER
       CHILD FOLDER (1)

Now mark that same message as read, again not moving the mouse thereafter.

    PARENT FOLDER
       Child Folder

Now move the mouse over "PARENT FOLDER" again.  It'll change back to:

    Parent Folder
       Child Folder

Pretty annoying...

I've been noticing this as well... has it always been this way? seems like it is a recent regression

Patch works like a charm and is well written.  Thanks René!

Committed to Subversion trunk (revision 33381).

Committed to gnome-2-18 branch too (revision 33382).

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

Guys, I think it needs a slight modification the the fix. It should bold the parent folder only in collapsed mode and not in expanded mode. I think we follow that for message threading also. It isn't inconsistent. 

If I understand you correctly, you're suggesting that when a new message arrives in "Child-Folder", instead of seeing this:

   INBOX
      PARENT-FOLDER
         CHILD-FOLDER (1)

you want to see this:

   Inbox
      Parent-Folder
         CHILD-FOLDER (1)

(CAPS denote bold text)

I have a few reservations:

  * If CHILD-FOLDER is scrolled off the bottom of the window, the user gets
    no visual indication that a new message has arrived.  I personally find
    that visual indication useful (notification plugins notwithstanding).

    Of course if CHILD-FOLDER is scrolled off the TOP of the window (i.e.
    the user is looking at the bottom of the folder list), there's no visual
    indication anyway.  So maybe it's not a big deal.

  * What happens when you expand a bolded folder?  Does it stay bold or does
    the bold jump to the child folder (which may itself be another collapsed
    folder).  Staying bold would be inconsistent because now both the parent
    folder and child foler are bold.  But making the bold jump around such
    that the user has to chase after it would be even more confusing (and
    probably quite irritating).

  * I guess I don't see a need for the behavior to be consistent with
    message threading.  I think you're comparing apples and oranges.

As we discussed on irc, lets wait for user comments. This is just more of a preference. 

Agreed.  No strong preference from me, despite my reservations.