I think I'm onto something here... Sorry for not supplying a patch this time 
but I swamped the source with some homebrew trace macros to be able to follow 
the execution path a little better...

I noticed that TreeItemMsgList::_numberFetchingStatus is set to LOADING in:

ObtainSynchronizedMailboxTask::syncFlags

but then it is not set to DONE although a reply for fetching flags is received.
I noticed that ObtainSynchronizedMailboxTask::handleStateHelper is called and 
has an if-branch for "resp->tag == flagsCmd" which now looks like this in my 
source: (added lines start at //TG)

    } else if ( resp->tag == flagsCmd ) {

        if ( resp->kind == Responses::OK ) {
            log("Flags synchronized", LOG_MAILBOX_SYNC);
            //qDebug() << "received OK for flagsCmd";
            Q_ASSERT( status == STATE_SYNCING_FLAGS );
            Q_ASSERT( mailboxIndex.isValid() ); // FIXME
            TreeItemMailbox* mailbox = dynamic_cast<TreeItemMailbox*>( 
static_cast<TreeItem*>( mailboxIndex.internalPointer() ));
            Q_ASSERT( mailbox );

            //TG set in syncFlags to LOADING but not set to DONE here...
            TreeItemMsgList *list = 
dynamic_cast<Imap::Mailbox::TreeItemMsgList*>( mailbox->_children[0] );
            Q_ASSERT(list);
            list->_numberFetchingStatus = TreeItem::DONE;

            notifyInterestingMessages( mailbox );
            model->emitMessageCountChanged(mailbox);
        } else {
            log("Flags synchronization failed", LOG_MAILBOX_SYNC);
            // FIXME: error handling
        }
        status = STATE_DONE;
        emit model->mailboxSyncingProgress( mailboxIndex, status );
        _completed();
        return true;
    } else {


This fixes the issue for me: when a mailbox is selected and a message is marked 
as read, the mailbox view reacts accordingly.

But1: At first I supposed the method
ObtainSynchronizedMailboxTask::handleFlags
is responsible for handling that response, but it doesn't seem to be called - 
at least in my testcase - should the _numberFetchingStatus flag be unset there 
as well?

But2: this manual unsetting of _numberFetchingStatus from several different 
places seems cumbersome and error-prone - is it OK for me to have a go and try 
to improve this situation? (accessor method or some RAII-based reference-
counting like magic, I'll have to dig into the source a little further to 
think of something specific...)

Cheers,

Thomas

Reply via email to