(You might want to subscribe to the ML; I had to moderate your mail and include you in the Cc list explicitly.)
On Friday, 14 June 2013 15:11:36 CEST, Mildred Ki'Lya wrote:
What i did is create a TreeView containing tags. When a mailbox is selected, the TagListModel (a new class I created) is populated with TreeItemMailbox::syncState.
That's an internal class which should, in my opinion, stay private to the caching layer and the ObtainSynchronizedMailboxTask. It looks like you need an access to all defined flags within a mailbox; that's a valid use case, of course. IMHO this should be done over an additional "role" argument to TreeItemMailbox::data. Patches with unit tests (very likely the test_Imap_Tasks_ObtainSynchronizedMailbox) for this are welcome.
the signal comes from the mailbox tree view, and is sent to the TagListModel::setMailbox (I took inspiration from MsgListModel that also changes when a mailbox is selected). And in setmailbox, I directly take the TreeItemMailbox::syncState::flags list to get the list of tags.
The problem with adding one more proxy model is that you will have to reimplement everything else, otherwise you won't be able to perform threading, sorting and searching, which is why I do not terribly like this approach. In my opinion, there shall be no more proxy models, and this filtering shall be implemented within the ThreadingMsgListModel, a layer which already includes the required functions for filtering and reshaping the mailbox contents.
Why isn't there a signal in TreeItemMailbox to notify when the SELECT command has completed?
The synchronization process is not yet complete at the time the SELECT is finished; some UIDs might be still unknown at this point, and the (per-time) FLAGS could very well be stale as well. Resynchronizing a mailbox could involve more commands; a single-roudntrip syncing oculd only happen on subsequent synces and when QRESYNC is involved. The right place to add this signal, if any, is at the time the ObtainSynchronizedMailboxTask is finished. Please keep in mind that any message can arrive at any other time, though, so messages with unknown UIDs or unknown flags could pop up at more or less any time later on; that might or might not be relevant for what you're doing (I know it bite me more than once). Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
