On Thursday, 2 May 2013 19:25:17 CEST, Mildred Ki'Lya wrote:
Now, how would I implement tags in Trojita ?
- I would first implement tag filtering in only one mailbox
(relatively easy to do so, just create a filtering model around
the current mailbox model)
Yep, this sounds like something which is doable. There's something similar
right now, see the PrettyMsgListModel::filterAcceptsRow function. There's a
couple of problems with it, though:
- It works on a wrong layer. Ideally, the filtering shall happen in a
GUI-agnostic model, so that it works in the QML version of Trojita as well.
- It won't work with threading, unfortunately. Due to the way the
QSortFilterProxyModel works, any item filtered out is removed with all of its
children. This means that a naive implementation of this filter would ignore
any new messages in a thread whose root message was already marked as read --
which would suck :).
I'll think about moving the code into the ThreadingMsgListModel itself -- it
already includes some level of filtering already (which is known to be buggy so
it needs some work), and this proxy model is always present anyway. If done
properly, it will result in no extra memory usage or other overhead.
- Then implement a virtual mailbox that would gather all
messages from all mailboxes
This is going to be very, very hard to do properly:
- The list of mailboxes can be extremely deep (some servers might export
enormous ML archives, theoretically)
- There's no universal unifying model (AFAIK) which would be suitable here.
Even Thomas' proxy in the multiaccounts2 branch would not work very well
because the individual mailboxes do not have an extra model each -- the
MsgListModel is created once per the GUI. There's no inherent reason for this
except for, well, saving resources.
Complexity-wide, I'm afraid this is not something to be done during evenings in
a few weeks.
- Then, perhaps combining those two, implement tag search in all messages.
I don't know if that's a good solution (now I think this might
not be). perhaps that souldn't be implemented as a filtering
model but rather use IMAP queries to avoid fetching all
messages.
Actually the existing code makes sure that the *keywords* are synced whenever a
mailbox is opened. On at least half-modern IMAP servers (which means those that
support the CONDSTORE extension at least, which now means also GMail AFAIK)
this is very cheap. So if the code moves into the ThreadingMsgListModel *and*
if we're talking about searching on top of a single mailbox, this won't have
any performance impact at all.
Searching across mailboxes is, however, going to be hard without server-side
support (no servers can do that yet AFAIK, and neither can Trojita).
As for the UI I don't have a definite idea, I was thinking of
splitting the left panel vertically in two. Mailboxes on top,
tags (could be collapsed) on the bottom.
Peronally, I was think more in the "let's filter the current mailbox" sense.
PS: I followed your posts on the IETF imapext mailing list and
wondered if you got anywhere with the SENDMAIL extension. is it
implemented in any server ?
There was no progress except a (very) experimental Dovecot patch, but I don't
think it ended up anywhere. This, too, is on the todo list :).
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
