Summary: | Existing IMAP account clashes with new POP3 account | ||
---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | claws-mail-bugs |
Component: | POP3 | Assignee: | users |
Status: | CLOSED DUPLICATE | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 3.17.3 | ||
Hardware: | PC | ||
OS: | Linux |
Description
claws-mail-bugs
2020-12-12 06:28:45 UTC
Create a mailbox for your POP account: /File/Create mailbox/MH... Correction: /File/Add mailbox/MH... That creates an empty mailbox, but it's not a "danwin - POP3" mailbox. So the left frame now shows: => danwin - IMAP => mail (MH) "danwin - POP3" is still missing from the frame. One or more pop accounts can share a single MH mailbox. Because what you see is not what you expect to see, based on a pre-conceived idea, does not make this a bug. > One or more pop accounts can share a single MH mailbox. I can see how that would be quite useful, so long as the user is in control of the decision. But at first the user doesn't seem to have control and the default behaviour is a POLA failure (https://en.wikipedia.org/wiki/Principle_of_least_astonishment). I created two C-M accounts in this order: 1. danwin - IMAP 2. danwin - POP3 So **POLA bug 1** manifested: only "danwin - IMAP" appeared in the folder frame, not "danwin - POP3". Why would a user intuitively expect acct 1 to appear but not acct 2? (I later discovered why POP & IMAP differ in this regard, but it's non-intuitive and doesn't diminish the shock of the user's first impression-- and it's still inconsistent behaviour when the top-level IMAP folder is created automatically) Then I notice that the POP3 acct has a "default inbox" field that crypticly mentions the IMAP folder (which has appears automatically associated to the IMAP acct). The documentation makes no mention of what to write in this field but the syntax is quite non-intuitive. That's **POLA bug 2**. **UI bug 1:** I later discovered that the "default inbox" field actually has a "browse" button to the right of it, which doesn't become visible unless the user widens the window enough to make it show up. The horizontal scrollbar at the bottom is insufficient for signalling to users that a browse button is cutoff if the user doesn't know there's a browse button in the 1st place. We only scroll when we know there is something to scroll to, and it looks as if the only object to run off the window is the "check mail every ... seconds" field, which many would ignore. A good fix would be to put a right arrow at the left of the field value, and have a pull-down of choices. **Documentation bug 1:** The manual should make it loud and clear that part of creating a useable POP3 acct entails manually creating an MH mailbox and pointing to it. This is not like Thunderbird where a wizard does what needs to be done. This is the only remark about it in the C-M manual: "Mail received from a POP3 account will be stored in an MH mailbox in the folder tree." It neglects to tell the user that they must create a POP3 mailbox as a separate step. Paul- I appreciate your guidance, which ultimately helped remedy my problems reported here. However, the four or so bugs I've exposed here remain bugs. The fact that your guidance was needed is in itself evidence that there are bugs here, as your guidance should not have been necessary. Now that I've overcome the C-M stumbling blocks and idiosyncracies, I don't need a fix for my sake but no doubt others will get burnt by the same POLA bugs as I have, even if they read the docs. I'm changing it from "INVALID" to "WONTFIX" b/c I have the power to and "WONTFIX" seems more appropriate. Of course, you can change it back if you insist. |