On Monday 25 July 2011 13:06:59 Jan Kundrát wrote: > > Hi Thomas, sorry for wasting your time here, I've done something very > similar yesterday, but forgot to push :(. Fixed now. Your analysis was > spot-on, but I decided to set the _numberFetchingStatus in > TreeItemMsgList::recalcVariousMessageCounts() instead. > No worries, the fact is: I had it fixed yesterday but was struggling with KMail so was unable to send it out - so not much time-wasting here except for MKail ;)
> > This fixes the issue for me: when a mailbox is selected and a message is > > marked as read, the mailbox view reacts accordingly. > > I still have to occasionally generate a mouse over over the mailbox in > the left column in order for the GUI to show an updated number; that's > likely an issue in my model code. > Oh I've never quite gotten a good grasp of Qt's Model Classes and especially subclassing them properly... > > 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? > > These are different "flags" (it lists all flags available for use in a > particular mailbox) than per-message flags, which are handled by > ImapTask::handleFetch -> Model::_genericHandleFetch -> > TreeItemMailbox::handleFetchResponse -> TreeItemMessage::setFlags. > I see. > > I usually tend not to bother with getters/setters "for simplicity", and > then start pulling my hair when debugging problems like this :). I'd say > that numberFetchingStatus() and setNumberFetchingStatus() would look great. > Been there, done that - a lot of times ;) > However, there's a small problem here [1]. I'm still a student, and > Trojita is subject of my Master's thesis, which means that there's a > limit on contributions I can accept at this point, especially in the > src/Imap directory. While the getters/setters are mostly just a cosmetic > change, I feel like saying this in advance. Generally speaking, there is > no problem with accepting advice (and I'll of course give a proper > credit to you in the thesis), small patches, cleanup changes etc, but > "big" changes should be limited to be outside of the IMAP features. For > example, contributing support for faster IMAP syncing via QRESYNC is > currently off limits, while adding support for encrypted/signed e-mails, > refactoring the SMTP code or implementing multiple accounts is perfectly > acceptable. > > I hope this won't stop you from playing with Trojita and messing around > with its source code; as I said, I'm grateful for every comment I get > and would love to improve myself. > Oh, I totally failed to see that wiki-page. Well as it is now, I'm quite pleased with the functionality on the IMAP part for me. The only changes I would implement would be of cosmetic nature I would say. But I think I will enjoy sinking my teeth into the EMail composing and sending part, since what I need for Trojita to become my master EMail client is the possibility to have several SMTP identities to choose from when sending a message and maybe some magic to automatically pre-choose the right one if the message being composed is a reply to another one... I guess this way we can work on the source without interferfing ;) I'll see in the next days/weeks. Cheers, Thomas
