Trojita has a button to mark emails as important. But there is no way to list them via the UI. The only workaround seems to be to make an imap raw search for :=FLAGGED, which is not an good solution. Reproducible: Always Steps to Reproduce: 1. Look for a way to show only marked emails Actual Results: There is none Expected Results: There should be a filter option Very important feature for some workflows, including mine.
Yeah, we really need something like this. Here's one possibility on how to implement it. Import the KDE's KF5 KRecursiveFilterProxyModel [1] and check the item's data(RoleMessageIsMarkedFlagged).toBool() in the acceptRow(). Later, this could be extended to filter based on existence of arbitrary tags (through RoleMessageFlags). Even better, that special snowflake in PrettyMsgListModel (the m_hideRead filtering) could be removed, which is wonderful because it just doesn't belong to a GUI-specific class. There's some possibility that this approach would be too expensive on huge models -- not in terms of IMAP traffic because flags are always synced anyway, nad have to be for various reasons, but in terms of the overhead of the C++ code. I think it's very much worth a try anyway. If you know some C++ code, please get in touch. Patches are welcome. [1] http://api.kde.org/frameworks-api/frameworks5-apidocs/kitemmodels/html/classKRecursiveFilterProxyModel.html
Is local filtering actually better than mangling FLAGGED into the sortfilter tasks?
> Is local filtering actually better than mangling FLAGGED into the sortfilter > tasks? Well, we have the flags anyway (for why we always sync them all the time, see section 2.2.1 of http://trojita.flaska.net/msc-thesis.pdf, and don't worry, it's cheap on reasonable servers). Using this information is much better than making another server-side search. Anotherquestion is whether to use yet another proxy model, or whether it makes more sense to perform a local client-side filtering in the ThreadingMsgListModel. My suggestion is to use a ready-made proxy at first because it's going to be much easier; the threading model's code is not really elegant, pretty fragile IMHO, so the more we can do outside the better. I'm aware that there's some risk here. If this has an overhead which is too big, we can always complicate the ThreadingMsgListModel later.
Created attachment 97994 [details] patch to show only marked mails I now had some time to try implementing this. I sadly failed with the KRecursiveFilterProxyMode-approach. That is just over my head, I do not understand whether that would replace the QAbstractProxy or where it would have to be plugged in. But I was able to just copy the way read messages are hidden. I understand that given the prior comments, that is probably not the best way, but it seemed to work fine for me. If you are okay with merging this, and I need to do something for that, please just state so.
@onli, Qt proxy models can be "stacked" on top of each other. That's for example how Trojita works already -- there's a huge model (src/Imap/Model/Model.cpp) which presents a lazily populated tree view of an entire IMAP server, including all mailboxes and all messages in there. You can see this in the GUI, check the IMAP -> Debugging -> Show full tree. The widget at the left edge of Trojita is powered by a proxy model which simply presents a transformed view of the entire IMAP model by only including mailboxes (in other words, everything else is filtered out). Similarly, the message listing is powered by another chain of proxy models. At first, only a flat list of messages is provided by src/Imap/Model/MsgListModel.cpp which filters out the IMAP's "everything" model by offering a view on just a single level in the tree. This flat list of messages is then processed by a very complex proxy, the ThreadingMsgListModel which adds a completely different tree structure based on the flow of messages. Finally, this threading tree is proxied by yet another model, the PrettyMsgListModel, which should ideally just format this for the GUI, but in practice it unfortunately also implements the filtering for unread messages. What I would like to get is a patch which inserts another proxy between the ThreadingMsgListModel and the PrettyMsgListModel. Please read through the http://api.kde.org/frameworks-api/frameworks5-apidocs/kitemmodels/html/classKRecursiveFilterProxyModel.html for why a simple reimplementation of a QSortFilterProxyModel::filterAcceptsRow() is not enough. I won't merge your patch because it attacks the problem on a wrong level -- and because it does not work when threading is active.
Thanks for the explanation. I'll give it another try (I might ask for some additional hand-holding in IRC, if that is okay). However, honestly, it does not sound that wrong to me for a GUI-class to also filter parts of the the view according to the current state. I'd be comfortable defining this as part of the formatting work. Maybe especially given how easy the code for that is, and that these two filters are the important ones – this does not have to snowball. > Please read through the http://api.kde.org/frameworks-api/frameworks5-apidocs/kitemmodels/html/classKRecursiveFilterProxyModel.html for why a simple reimplementation of a QSortFilterProxyModel::filterAcceptsRow() is not enough. Because messages deeper in threads would not be found, right? I thought if that were a problem, it could be solved the same way `RoleThreadRootWithUnreadMessages` seems to solve that for unread messages.
> I might ask for some additional hand-holding in IRC, if that is okay Sure. > I'd be comfortable defining this as part of the formatting work. It is not specific to QtWidgets, though. For example, Dekko, Ubuntu's e-mail client which is impleemnted in QML, builds on top of our code. It doesn't use the PrettyMsgListModel because that's just an implementation detail of the QTreeView -- we could have just as easily used custom delegates, I suppose. > Maybe especially given how easy > the code for that is, and that these two filters are the > important ones – this does not have to snowball. The problem is that the code which supports the unread message state in particular goes deep into the rest of the models. The "is unread" is special because of the associated "was unread" tracking, but that's not all. Because the model really operates on a wrong layer, it has to support the tree structure of the underlying data (see RoleThreadRootWithUnreadMessages), and even despite that, our code has to deactivate threading when a search operation is active. That just sucks. > Because messages deeper in threads would not be found, right? Yes. > I thought if that were a problem, it could be solved the same way > `RoleThreadRootWithUnreadMessages` seems to solve that for unread messages. This existing feature is extremely invasive and it by definition not extensible. Really, it's a hack.
Hello, I am also vitally interested in that feature. I find filtering (a button) sitting maybe in the right corner of Quick Search field, to show only flagged (also only unread), really missing in Trojita. Also the Yellow flagged email is pretty hard to distinguish from gray (unflagged), can we please make them more distinctive, eg. 1. Make flagged "flag" icon to be red (instead of yellow) 2. Make unflagged "gray" to be more light gray. Thank you for really nice mail client.
Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/ Sorry for the inconveniences.