On Friday, 18 October 2013 02:05:05 CEST, david.scott....@gmail.com wrote:
having to set the sort order on every running of the program
What particular sort order does she want to use? I believe that if she toggles the order by View -> Sorting -> Descending, that shall be remembered just fine.
The problem is that if the order is changed via clicking on the Date column, this actually triggers a rather exepnsive server-side operation, and I've so far tried to not trigger this operation unless really needed. In short, the problems/symptoms are this:
- fact: Flipping the order is trivial; it does not involve any network IO. Trojita shall always support it. It doesn't matter what particular order was selected, once it's already sorted, the reversal itself is a no-op IMAP-wise.
- fact: Showing the list of messages in the "order they have been added to the mailbox" is trivial and does not need any other network IO.
- problem: The "Date" column sorts by the date of the message, not by the date when it was put into the mailbox (when I move a two-year old message from mailbox B to INBOX, it will be shown as the "latest" in INBOX when sorting by the time it was stored into a mailbox).
- bug: Trojita has "No sorting" (meaning "when it was added to the mailbox"), "Arrival" (meaning when it was delivered to the IMAP server) and "Date from message headers". Users can sort by any of these, but the two former options both involve extra network IO (and depend on an IMAP extension, so they won't work on e.g. gmail). These shall definitely be made more intuitive in the GUI.
I am not sure what would be the best way of handling these. What about restructuring the View -> Sorting menu to show the date-related options as a submenu? The message listing widget could be changed so that a clik on the Date field shows the same popup, then.
Suggestions are welcome.
and having to set the column widths
Weird, these shall be remembered automatically, but there's a bug -- the code which saves this as a preference is only triggered by resizing the window, or changing the sizes of the big widgets like msglist, msg view, folder view etc.
I'll patch this, thanks for reminding me.
having to select the inbox on program startup
Yes, that would be cool, but it's tricky due to the asynchronous nature of the code -- https://bugs.kde.org/show_bug.cgi?id=321368 .
or having to ask that remote graphics be loaded for every viewing of every email.
There is a real-world privacy issue associated with this -- if a spammer sends you a mail and the MUA is configured to autoload the images, they will know that a) your address exists, b) you have read their mail. Remember, the images can very easily point to something recipient-dependant like http://evil.example.org/trackme.png?mail=j...@flaska.net .
There was an old thread about this -- see the discussion at http://www.mail-archive.com/trojita@lists.flaska.net/msg00338.html . I'll be OK with adding a server white list, but again, this is a feature which will not be terribly useful for people who just "want to see the pictures", and quite frankly, I won't add a checkbox for "just load the images unconditionally, I *know* I want to be tracked".
Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
