When the "Show messages in threads" option is checked, only one level of threads is shown. I.e. below the first message of a thread, the thread structure is flat. This would be correct only if all messages in the thread were replies to the first message. Now we have (regardless of the real structure): |-- |-- |-- |-- |-- |-- |-- A real thread usually looks something like the following: |-- |-- | |-- |-- |-- |--
This functionality depends on a server-side support ([1] and [2]) for e-mail threads. Chances are that your IMAP server might only support THREAD=ORDEREDSUBJECT which indeed sucks exactly like you described. You can check the dialog under the hamburger icon -> IMAP -> Debugging -> IMAP Server Information for a list of announced capabilities to confirm this. We do not do client-side threading because doing that would require Trojita to download a subset of header for each message in an entire mailbox. It is a design decision -- we rely on IMAP features so that the server can do work on our behalf and that we do not have to transfer data that we do not really need. Unfortunately, this means that the end user experience is worse in case their e-mail server leaves something to be desired. Right now for example we won't do any threading on GMail because GMail servers have their own proprietary extension for one-level-deep threading and because we don't have code to work with this non-standard extension yet (patches welcome). If you have suggestions on how to better reflect this state in the UI, please propose them here. If someone wants to contribute code which adds support for client-side threading, I'll be happy to review the patches and to provide suggestions on how to best approach the problem. However, I don't see myself actively working on this. [1] https://tools.ietf.org/html/rfc5256 [2] https://tools.ietf.org/html/draft-ietf-morg-inthread-01
(In reply to Jan Kundrát from comment #1) > This functionality depends on a server-side support ([1] and [2]) for e-mail > threads. Chances are that your IMAP server might only support > THREAD=ORDEREDSUBJECT which indeed sucks exactly like you described. You can > check the dialog under the hamburger icon -> IMAP -> Debugging -> IMAP > Server Information for a list of announced capabilities to confirm this. Pardon my ignorance... what's a hamburger icon? > We do not do client-side threading because doing that would require Trojita > to download a subset of header for each message in an entire mailbox. It is > a design decision -- we rely on IMAP features so that the server can do work > on our behalf and that we do not have to transfer data that we do not really > need. Unfortunately, this means that the end user experience is worse in > case their e-mail server leaves something to be desired. Right now for > example we won't do any threading on GMail because GMail servers have their > own proprietary extension for one-level-deep threading and because we don't > have code to work with this non-standard extension yet (patches welcome). Yeah, I read about this decision in Trojita a couple of years ago. Understandable. I just didn't know that this was a similar problem. For reference, the IMAP server I'm using is Zimbra. > If you have suggestions on how to better reflect this state in the UI, > please propose them here. Not sure what you mean. If the client doesn't know about the threading, how could it be reflected in the GUI? > If someone wants to contribute code which adds support for client-side > threading, I'll be happy to review the patches and to provide suggestions on > how to best approach the problem. However, I don't see myself actively > working on this. The code that supports this surely exists somewhere. Other clients, incl. Kmail, support this threading. Wouldn't it be possible to reuse it? (I'm not a programmer, so I can't contribute code, unfortunately.) > [1] https://tools.ietf.org/html/rfc5256 > [2] https://tools.ietf.org/html/draft-ietf-morg-inthread-01
(In reply to Robert Kratky from comment #2) > Pardon my ignorance... what's a hamburger icon? Ah, that's probably a KDE-ism. Since you haven't said what version you're on and because newer versions of Trojita merged the main into the toolbar by default, you have to click an icon in the toolbar to get access to it. It's on a lower left corner on this screenshot, http://trojita.flaska.net/img/2016-03-22-trojita-home.png, and someone suggested that it looks like a hamburger :]. > > If you have suggestions on how to better reflect this state in the UI, > > please propose them here. > Not sure what you mean. If the client doesn't know about the threading, how > could it be reflected in the GUI? You invested time by opening a bugreport which means that you were surprised to see broken threading -- I understand that, that makes sense, and I appreciate the feedback. So maybe there's something that we can do so that we won't get a similar bugreport in future? (Apart from actually implementing this :). ) Maybe a pop-up or a mouse-over text next to the action in the menu? Something else? A color-coded icon showing the "level of suckiness" of the IMAP server? I'm looking for suggestions. > The code that supports this surely exists somewhere. Other clients, incl. > Kmail, support this threading. Wouldn't it be possible to reuse it? (I'm not > a programmer, so I can't contribute code, unfortunately.) Yes, other projects have solved this, but taking code from an external project or even simply using a well-maintained library needs integration work. And because I don't really need this feature myself, I don't see me investing my time to write this. Patch review and guidance, yes, writing code, no.
(In reply to Jan Kundrát from comment #3) > (In reply to Robert Kratky from comment #2) > > Pardon my ignorance... what's a hamburger icon? > > Ah, that's probably a KDE-ism. Since you haven't said what version you're on > and because newer versions of Trojita merged the main into the toolbar by > default, you have to click an icon in the toolbar to get access to it. It's > on a lower left corner on this screenshot, > http://trojita.flaska.net/img/2016-03-22-trojita-home.png, and someone > suggested that it looks like a hamburger :]. Thanks. You were right, just THREAD=ORDEREDSUBJECT :-/ Speaking of newer versions -- can you set up nightly builds for Fedora 25, too? I now see that the 0.7 release that I use is not exactly new. > > > If you have suggestions on how to better reflect this state in the UI, > > > please propose them here. > > Not sure what you mean. If the client doesn't know about the threading, how > > could it be reflected in the GUI? > > You invested time by opening a bugreport which means that you were surprised > to see broken threading -- I understand that, that makes sense, and I > appreciate the feedback. So maybe there's something that we can do so that > we won't get a similar bugreport in future? (Apart from actually > implementing this :). ) > > Maybe a pop-up or a mouse-over text next to the action in the menu? > Something else? A color-coded icon showing the "level of suckiness" of the > IMAP server? I'm looking for suggestions. Ok, a popup that would warn of the inadequacies of the IMAP server (shown when a user clocks on the threading toggle) could help. > > The code that supports this surely exists somewhere. Other clients, incl. > > Kmail, support this threading. Wouldn't it be possible to reuse it? (I'm not > > a programmer, so I can't contribute code, unfortunately.) > > Yes, other projects have solved this, but taking code from an external > project or even simply using a well-maintained library needs integration > work. And because I don't really need this feature myself, I don't see me > investing my time to write this. Patch review and guidance, yes, writing > code, no. Is Trojita featured on any of the open-source market place websites where I could set up a bounty for this. As I said, I can't contribute code, but I'd be willing to contribute money.
The penultimate sentence was meant to be a question: Is Trojita featured on any of the open-source market place websites where I could set up a bounty for this?
Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/ Sorry for the inconveniences.