Re: possible new sort option



A new branch 'threading' has been added to Balsa's GitLab site[0]. It currently has the first part of a 
proposed change to Balsa's message threading.

The three radio buttons on the 'View' menu have been replaced with a simple 'Thread messages' check-box, and 
checking it enables a modified JWZ threading algorithm which constructs threads only by message-id, ignoring 
the subject header.

At present there is no user interface to request full JWZ threading, although the code for it still exists. 
It doesn't belong on the 'View' menu. It should be a per-mailbox option, not global, so it doesn't belong in 
the 'Preferences' dialog. That leaves the mailbox 'Properties' dialog, so the next step is to add a check-box 
there. Threading is also a per-mailbox option, but not currently shown on the 'Properties' dialog, so perhaps 
we should add two check-boxes:

[ ] Thread messages
[ ] … by subject as well as by references

with the second grayed out if the first is not checked. Opinions?

Oh, by the way: this message *looks like* a reply to my earlier post, but is actually a fresh post, with no 
'References' header. JWZ threading will place it in the earlier thread, because of the subject, but the Balsa 
built from the 'threading' branch will make it the head of a new thread. Happy testing!

[0] https://gitlab.gnome.org/GNOME/balsa

On 08/09/2018 06:10:43 PM Thu, Peter Bloomfield wrote:
Hi André:

On 08/08/2018 09:24:06 AM Wed, andré via balsa-list wrote:
Le 2018-08-06 à 19:40, Peter Bloomfield a écrit :
On 08/05/2018 11:35:26 AM Sun, Peter Bloomfield wrote:
I take it as a consensus that thread-date-sorting should be implemented--right?

Haven't seen any dissenting opinions

Questions:
1. Should it replace head-date-sorting, or be a preference item (defaulting to thread-date)?

Replacing would keep it much simpler for (especially new) users.
Then the questions becomes threading or not.

2. Should we add an option to *not* gather threads by subject?

Would favour only by message id and "not* a fall-back by subject, to avoid the problem you outline below.
Having an occasional message shown outside its' thread is much less of a problem.
An option makes it more complicated.  If it exists, the default should be to *not* fall-back to subject.

I rather think the option may still be needed, perhaps for mailing lists?

3. Do we need simple threading?

One threading method is less confusing.

Agreed!

Thanks for the thoughts! Absent any last-minute objections, I'll merge the branch into master, replacing 
head-date by thread-date. I'll open a new branch for the more extensive changes involved in 2 and 3, which 
require UI and string changes.

Best,

Peter

Attachment: pgplAj8nzllSl.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]