thunderbird-patches
thunderbird-patches copied to clipboard
Betterbird
Upside down thread
Hi All,
I've been trying all sort of things, as well as various extensions. If you take a look at the following:
You can see that the latest email in the thread is on the bottom of the thread. I still want everything sorted by the date descending, but for threads, I'd like to see the latest email at the top (this is similar to Outlook I believe), this way, I prioritize the latest in the thread and can probably collapse the thread to be able to fit more emails in the pane.
Is this something that be done in Betterbird? Or is this part of an extension? Or is this not a capability that is available at this time?
If it is not available, could I ask that this be an enhancement for the future please?
Many thanks.
b
With threaded display, the last received messages gets inserted into the thread tree at the appropriate location, an many cases at the end, or somewhere in the middle. That's a disadvantage of the threaded view. But how else could it be done in a hierarchical tree? Can you send a mock-up as a suggestion?
So here is a very rough mock up. You'll see that the latest message (just for each thread) is at the top, not the bottom. This means that is should show up first when you're looking at the unread messages. Hopes this helps
Sorry, we can't make sense of your mock-up. We've prepared this drawing:
The numbers are the order received or date. On the top left you have the original view. On the right hand side you can see a few options: At the top, the replies are indented to the left but the reverse-date order is applied. The second from the top is mirrored, both boxes and lines. On the bottom image only the boxes are mirrored. You can see that it doesn't work well with the connection lines.
The upside down ones is what I'm looking at. The idea is that the most recent message in the thread is on top. Currently, if the thread is collapsed, (at least in the Unified View), I can't actually see that there is a new message. Doing it this way, new messages relating to the thread will appear on top. It also follows logically because when you reply to each message, the quoted message follows
I hope this makes it clearer. Thanks.
We've understood your idea. It's annoying to look for new messages at the end of a long thread.
But the graphical reversal (let alone the implementation) isn't straight forward. So did you look at the three proposals on the right? (Looks like the collapse arrow should go to the top.) Looking at your mock-up again, maybe you meant the top right solution.
That's a great solution, and consistent with the current implementation. Thanks for considering my suggestion.
This won't happen right now, we're preparing for version 115 to be released in the summer. But we keep the request on file.
Oh please, no rush. I just thought this would be something others and I would find useful as well. Thanks for considering this request.
"You can see that the latest email in the thread is on the bottom of the thread. I still want everything sorted by the date descending, but for threads, I'd like to see the latest email at the top"
I think the real issue is that, the sort setting is not applied to threads.
If the sort setting would be applied for threads as well, your issue should disappear too. Since the latest E-Mail would be on top.
I think the real issue is that, the sort setting is not applied to threads.
If the sort setting would be applied for threads as well, your issue should disappear too. Since the latest E-Mail would be on top.
So much this! If the threads just followed the sort properly (date, subject, unread, etc) I think the problem should solve itself.
Also I want to point out an issue w/ the proposals above. Not sure if it's a typo or smth but I think it matters.
Note the order of the original messages at the 2nd level (first level indent): 2 3 5
Now look at the flipped orders (top to bottom)
3 2 5
Why would that be the reversed order? I would have expected these to sort as:
5 3 2
If that's just a typo then I apologize for being pedantic. If it's not a typo then I think it's a good thing I'm pedantic lol.
Thanks.
Like this, right?
The reversed threading is on the to-do list. Let's see how the activities around the new version 128 turn out.
Like this, right?
The reversed threading is on the to-do list. Let's see how the activities around the new version 128 turn out.
Yep, exactly!
This is literally the biggest non-starter on threads bc I default my messages view to newest first and threads are always backwards. So it also makes identifying threads w/ new msgs in them difficult.
You fix this and you're a legend in my book :)
thx!
That's fantastic right there.
Question - how does this behave when collapsed? i.e is it still going to be the original/oldest message shown in the messages list pane? Is there a way to show the newest?
Thanks.
Whilst the screenshots are not a mock-up, they are from WIP code (which I forgot to mention in the commit message). Further checkins will follow, including fixing the expand/collapse behaviour, the thread lines and the chevron orientation; since we're expanding above, it should point upwards. This is all fairly difficult since it needs to be fiddled into ancient C++ code in various places. For starters, it took quite some time to figure out where the thread children are actually added and that their order is NOT determined by sorting, but they are added in database order and before they are added to the database in date order. Since you don't want to rebuild the database every time you change sort order, you need to juggle all that in the fly.
We'll continue this in the background during the "summer hole" where not much else seems to happen.
Question - how does this behave when collapsed? i.e is it still going to be the original/oldest message shown in the messages list pane? Is there a way to show the newest?
That's a good question. If we show the thread parent (oldest) message, it will looks odd, since it's visually not sorted by date, since the thread parent is assumed to have the date of the newest thread child, see: https://bugzilla.mozilla.org/show_bug.cgi?id=20385.
Showing the newest message may be hard to do since the message is not the thread parent. Also, it has an indentation, so when all collapsed, it will look really weird.
With this deliberation, it might be best to show the thread parent. So the features for reverse threading when sorted by date descending would then be:
- Expanding upwards.
- Upward pointing chevron/twisty
- "Natural" sort order of all rows when all thread are expanded.
Just for the record: The threaded view works like this: The only "real" rows are the thread parent rows, they are sorted by date, and the date not the date of the thread parent message, but the date of the newest child.
After sorting, the children are fetched in database order and glued into the view. This "reverse threading" implementation reaches into the glueing phase and glues the children in reverse order, also pushing the thread parent to the bottom: https://github.com/Betterbird/thunderbird-patches/blob/41053f71dff4d7602337c08108418c8c0f2c721f/128/features/feature-305741-reversed-threading.patch#L121 (and following 12 lines). That's all cool since the view is just a set of three arrays: header array, flags array and level/indent array. You can swap entries in the array to get a different order in the list. It would be hard to display a different message, since that would mean replacing the message header and its flags/levels in the arrays, but when querying the displayed message via its header, it wouldn't be a thread parent any more and things will go downhill.
Question - how does this behave when collapsed? i.e is it still going to be the original/oldest message shown in the messages list pane? Is there a way to show the newest?
That's a good question. If we show the thread parent (oldest) message, it will looks odd, since it's visually not sorted by date, since the thread parent is assumed to have the date of the newest thread child, see: https://bugzilla.mozilla.org/show_bug.cgi?id=20385.
Showing the newest message may be hard to do since the message is not the thread parent. Also, it has an indentation, so when all collapsed, it will look really weird.
First, I'm not a coder. I'm a sysadmin, I've worked adjacent to devs and coders but I am not one so if I need a bit of slack please allow me. I think I understand the [major] difficulties involved. At least I hope I do, so this is my take:
It may not be necessary to take my request literally.
What I mean is that when the thread is collapsed, it wouldn't matter if I saw the actual most recent message or if it was just an illusion that it was.
If you can update the text contents of the columns in the message list view after the sort orders are built (and if I'm reading below correctly that can be done just by altering the 'level/indent' array) then that's probably enough. Copy the sensible columns - probably date, subject, read status and sender/from fields, maybe others - from the newest message and write them into the arry over the thread parent's. That's the 'illusion'.
Once the thread is 'opened' (uncollapsed) the parent returns to showing it's native/original col values and the newest message shows it's own values.
Hopefully that makes sense to more than just me.
With this deliberation, it might be best to show the thread parent. So the features for reverse threading when sorted by date descending would then be:
- Expanding upwards.
- Upward pointing chevron/twisty
- "Natural" sort order of all rows when all thread are expanded.
Just for the record: The threaded view works like this: The only "real" rows are the thread parent rows, they are sorted by date, and the date not the date of the thread parent message, but the date of the newest child.
After sorting, the children are fetched in database order and glued into the view. This "reverse threading" implementation reaches into the glueing phase and glues the children in reverse order, also pushing the thread parent to the bottom:
https://github.com/Betterbird/thunderbird-patches/blob/41053f71dff4d7602337c08108418c8c0f2c721f/128/features/feature-305741-reversed-threading.patch#L121
(and following 12 lines). That's all cool since the view is just a set of three arrays: header array, flags array and level/indent array. You can swap entries in the array to get a different order in the list.
This is what I'm interpreting as you being able to just overwrite in the array to be able to alter the appearance of the messages list view on the fly and for mimicking the newest message when thread is collapsed.
It would be hard to display a different message, since that would mean replacing the message header and its flags/levels in the arrays, but when querying the displayed message via its header, it wouldn't be a thread parent any more and things will go downhill.
Understood.
Here's what we have so far. We'll fix the chevron/twisty direction and the connecting lines.
https://github.com/user-attachments/assets/8b6d3bca-02cc-41e5-ab56-ceee33f494a2
This is complete now, you can try it in BB 128 for Windows: https://www.betterbird.eu/downloads/get.php?os=win&lang=en-US&version=future
We're still considering whether it's worth the effort to backport to BB 115.
See the Downloads and Release Notes pages.
BB 115 backport: https://www.betterbird.eu/downloads/WindowsInstaller/betterbird-115.13.0-bb30-latest-build3.en-US.win64.installer.exe
Now: https://www.betterbird.eu/downloads/WindowsInstaller/betterbird-115.13.0-bb30-latest-build4.en-US.win64.installer.exe
Hmm, works if nothing moves, but new messages don't get put into the right spot. Should be fixable.
This is turning our to be a nightmare. There are so many places in the code which assume that thread children are underneath the thread parent and that collapsing or expanding a thread doesn't change its it position. With reversed threading the children are above and collapsing moves the thread parent up by the number of children which no longer show, expanding moves it down.
We'll have to pull it from the release next week and give it more time.
Update: So reversed threading works when lightly tested in "normal" folder views, quick filter views, and virtual folder views (unified/search folders). It doesn't work in "search" views so far, so for example a Gloda result view. Getting there.
This should work well enough now, please try one of these builds: https://www.betterbird.eu/downloads/128-Preview/betterbird-128.0.1esr-bb5-build7.en-US.win64.installer.exe https://www.betterbird.eu/downloads/WindowsInstaller/betterbird-115.13.0-bb30-latest-build10.en-US.win64.installer.exe https://www.betterbird.eu/downloads/LinuxArchive/betterbird-115.13.0-bb30-latest-build10.en-US.linux-x86_64.tar.bz2 Please take a look at the release notes for details.
EDIT: Those builds no longer exist, check the release notes for the lastest released versions.