[rfe][thread view] column based layout

[0x64746b]

Request

I'd very much like the thread view to be column based, so that the (equally spaced (cf issue #17)) dates are nicely aligned to the right of the window.

cf Thunderbird's layout for reference.

Challenges

• The thread tree would span across a column
• Column widths would have to scale with the window size.

[pazz]

I see how this would be nice, but I'd like to first fix the current display properly, meaning: Use urwids recent treewidgets to display a tree. The current thread buffer is complicated and ugly code that resulted from my inexperienced attempt to display trees nicely.. But anyway, having a table layout instead of a tree layout would require to use a different body widget, so if s/o wants to start hacking on this: kick ThreadBuffer.rebuild and replace ThreadBuffer.body with another box widget..

[0x64746b]

I'd like to first fix the current display properly

yeah, cool, I just consider this a reminder for an optional future improvement ;) thx dtk

[pazz]

I just realised an issue with this: If you display all messages in a thread, one per line, a table based layout works nicely. But what should happen in case you select a message? possibility 1: you unfold a message widget like in the current view. Isn't that going to look strange with the rest of the treads neatly aligned into a table? also, in a Table widget (urwid.GridFlow I reckon) this would be impossible i think: you would have to be able to add widgets across table elements to display complete lines.. possibility 2: message selection opens yet another type of buffer that displays single messages. I consider that a bit against the philosophy of displaying all messages of a thread together..

opinions?

regarding your second challenge: That's actually no problem as urwid.Columns contains elements that may be either of fixed length or carry a weight, that specifies their importance relative to the other columns in the same line.

[0x64746b]

possibility 1: you unfold a message widget like in the current view. Isn't that going to look strange with the rest of the treads neatly aligned into a table?

I don't think so. So far, extended messages are indented according to the thread level of the message. You would probably want to keep that appearance, but I definitely wouldn't mind the message spanning additional columns (like tags and timestamp) from there on to the very right of the window.

Actually, the more I think about that solution, the more I like it, since it makes the thread line a more distinctive, well structured header line to the extended body, which might increase readability especially if many consecutive mails are expanded and the thread line serves as a optical limiter/divider.

also, in a Table widget (urwid.GridFlow I reckon) this would be impossible i think: you would have to be able to add widgets across table elements to display complete lines..

true. wantz this feature! can I haz it pleaz?

possibility 2: message selection opens yet another type of buffer that displays single messages. I consider that a bit against the philosophy of displaying all messages of a thread together..

Well, I personally wouldn't be that hard on this solution, since I actually never liked sup's thread view that much; usually found it to be quite unclear with many extended mails, though that might be something that might be improved with a better colour scheme on my side (maybe using stronger colours for the mail headers or sth).

Actually, I see a third option: One might do it thunderbird style and display the selected message in a preview window underneath the thread table, that gets updated upon selecting the next message. Only selecting the message with 'return' might open the message in a new buffer. I think mutt does something similar.

I have to admit though, that I never heard of

the philosophy of displaying all messages of a thread together

, so ain't that committed an' rather flexible on abandoning it ;)

On a somewhat related topic, though: Does github provide a mailing list for this project? These decisions might prove to be a rather fundamental departure from the design decisions of notmuch's emacs client. Discussing them on a mailing list rather than in tickets might expose them to a wider (potential) audience and lead to more generally accepted solutions?

[0x64746b]

One might do it thunderbird style and display the selected message in a preview window underneath the thread table

'though that would mean that one may only see one mail at a time

you would have to be able to add widgets across table elements to display complete lines..

maybe one could put columns into rows, weight them the same in all lines (so they look aligned duck) and then put expanded messages into a new (interlacing) row without columns?

[pazz]

let's skype some time soon, and i bring you up to speed as to what you can do with urwid and what you can't

[pazz]

cf the mailing list: As far as I know, there are <5 users so far. I think discussing this project on the notmuch mailing list is appropriate: http://notmuchmail.org/mailman/listinfo/notmuch The convention there is to just prefix a subject with a keyword in square braces.

[pazz]

How about this idea instead:

Instead of a Search and a Thread view, we have Threadlist (search) and a Messagelist view. The messagelist mode would list e.g. all messages in a thread, possibly in a table layout. But You could display all sorts of subsets of your messages in such a view. Particularly, instead of searching for Threads, you could directly search for messages and display the results in a messageview. "select" in this mode just unfolds the messagewidget. A view for a single message is equivalent to a messagelist displaying a singleton set.

It gets tricky if you want to display trees, and more so if you display a large number of messages, which then have to be loaded dynamically like search results atm.

[0x64746b]

I had the chance to talk a bit to teythoon about the threadview and was relieved to find that he found the concept somewhat... cluttered too. What came to my mind a few times already: I think it would help quite a bit to have the headers and body indented as much as the [-> from (date)] headline (so far, they are indented up to the beginning of the level indicating arrow instead of up to its head) Hope you get what I mean. I'd hope this to be a small refactoring (compared to the column based view), am not sure though if it can be done (monospaced font, two spaces? duck ;P).

Gotta run dtk

[pazz]

since my response seemed to get lost (possibly alot's fault wonder) I'll restate: Knock yourself out patching this buffer. I intend to replace it anyway with something more advanced. As stated earlier, the idea is to have a message-set-buffer, that displays a collection of messages as a list in the spirit of the current search buffer. That way one could

1. directly search for messages and e.g. simulate a classical folder based MUA (search for msgs matching "folfer:X"
2. display msgs in a single thread (search for msgs in "thread:tid")

Hopefully this new buffer allows more than one "sort options" and a "by thread" sort utilizes urwids new TreeWidgets.

If you'd like to work on this or just want to contribute a short-term fix for the current buffer: gogogo :)

[pazz]

i can't belive this is still open. threaline widgets are configurable as documented here: http://alot.readthedocs.org/en/latest/configuration/theming.html#highlighting-thread-lines-in-search-mode . in particular, one can simply fix the width of all displayed parts, which will result in the ui looking like a table.