Geary's current design to is default to the account email address of whatever folder you're currently viewing.  Since people are "in that world" when looking at a folder w/ that account, we feel that makes the most sense.  For example, if I'm looking at jim@yorba.org's Inbox and I select "New message", it rarely makes sense for the composer window to default to my home email address.

I'm closing, but if you want to make a more thorough case, feel free to re-open and explain why you think a single default mail address makes sense.

I understand your point, and how geary's design is. And i don't need an overall default mail adress, but the option to set a default emailaddress for each account (which has multiple addresses available).

I hoe you will reconsider this option.

You're right -- this would be a sensible thing to add.  I misread the bug in the same way as Jim, so I've edited the title to make this clear it's a per-account setting.

*** Bug 767328 has been marked as a duplicate of this bug. ***

Created attachment 331243 [details]
Screenshot showing the UI

I've got a *very* dirty branch up on https://github.com/tshikaboom/geary/tree/preferred-address.
It's far from being functionally complete, but I'd like to know if that kind of approach would conceptually be good.

I've introduced a "preferred_email" field in geary.ini which is optional, if it doesn't exist then the account would default to its primary/default email address.

I also took the liberty to implement alternate address editing through a popover, would that be cool with everybody? IMHO it looks cool and gives us a cleaner UI, without actually removing functionality. The "add" button would be the last row, a remove button would be present in every row to delete an account (except of course the primary account).

This does not alter the UI elsewhere though at the moment, ideally the composer window would also be hooked up to this stuff.

Thoughts? Opinions? :-)

To be more precise, clicking on a row would then assign the associated email address to be the preferred one. This is immediately reflected in the UI (checkbox in the row and the button's label).

Sorry for the extra email.

To actually test this out, one should manually add a line in geary.ini as follows:

preferred_email=<email>

where <email> is one of the alternative email addresses already added to the alternative addresses list. There is no add functionality at the moment...

Oh, this is almost exactly what I had in mind, thanks!

So, a few things to address with the UI, based on the screenshot, would be:

1. In the account UI, there needs to be some way of indicating that additional addresses can also be added, and maybe also that if any have been added that they exist. At the moment the UI looks like the button is just for modifying the primary address.

One approach would be to changing the label in front to "Email addresses". It's a bit weird that a button has a second label however.

Perhaps the button should just continue to have static text, say "Email Addresses", since per the UI mockup in Bug 714104, the plan is to put the primary email address in the HeaderBar for the settings anyway - hence using it as the button's inner label may end up being redundant.

I'm open to other suggestions, but do keep the UI mockup in Bug 714104 in mind.

Also, I assume the "Email" text entry would be removed, right? The email button should probably be moved up above the checkbox options to replace it.

2. About the popover itself, I would use either the tick mark, or the "Primary Address" label, but not both. The latter is probably the one to keep, since it could be ambiguous about what the former means.

Also, what are you thoughts for when the user clicks the "+" button? I'd be inclined to avoid popping up yet another window/popover, so maybe adding new entry to the ListBox with a text entry and accept cancel buttons would work?

1. What about
- we indeed replace the email entry with the button, the dimmed label on its left would still be something to the effect of "Preferred addresses"
- if no additional addresses are configured, then the button's label would be similar to what we have now ("Additional email addresses..."). If the user has selected a preferred address, then that would be shown as the button's label.

It still leaves us with the question of what to do if there's more than one address and the user still has its primary address selected as the "preferred" one.

2. The GNOME HIG actually prefers to use a subwindow for editing lists, would it be useful to explore this? I find it a bit overkill for what we're trying to do, an account usually does not have many additionall addresses configures. Though with a subwindow we could use a popover in the list for entering the new address. Even though I'd also lean myself towards the popover for subjective reasons.
I'm trying to find some real world examples in GNOME where there'd be a situation where a list could be edited (inline and not in a popover with a text entry a'la recent Nautilus) and a "default" item be selected, there does not seem to be any..

We also could put this stuff in a section (tab) on its own, then we get the added benefit of having a logical place for future settings in there, if any, say an "append a Reply-To: field" (I'm inventing here, but I know Evolution does that for example).

Oh, I missed the primary/preferred distinction. Wouldn't it be best to avoid having that extra notion? That is when the user changes their preferred address, it's the primary address in the account info that gets updated. That's pretty much the whole motivation for Bug 714643. It might be that some more work needs to be done on that bug to prevent things exploding when the primary address does change (the GMail login used, for example), but that's well worth doing. I'll have a look at it.

Anyway, the reason why I was favouring simply using "Email addresses" as the button label was that it captures both changing the primary/preferred use case and adding additional addresses use case at once - it's just where you go to change your email addresses, and users don't need to know or understand what the difference between primary/secondary/additional addresses are.

I'd rather not add additional tabs to the accounts dialog - we want to keep it to 3-4 max so that a horizontal tab bar can still be used for consistency with other GNOME app's prefs. Hence using auxiliary dialogs/popovers for secondary functions like this is the way to go.

Maybe another solution is to use a text label instead of the button (text in parens would be dimmed):

 Email address:  primary@example.com (+3 additional)
                 [ Edit addresses ]

But again, taking into account the fact that the Accounts dialog will likely end up displaying the primary/preferred address email in the HeaderBar title, repeating it here again, either as a plain text label or in the button's label is redundant.

For adding a new address in the popover, there is the vaguely similar case in the Language Selector of the Region & Language control panel - clicking the vertical dots reveals a search bar, but that feels a bit klunky. It might still work though if entry and associated buttons were added to the list as its own row, rather than below it?

I'm not a fan of using a subwindow for adding addresses either, but perhaps worth exploring if the above doesn't work well? I'm thinking of something more like the modal dialog that appears when adding a new directory in Nautilus, rather than the popover used to change a file name.

If neither inline or subwindow works well, it might be the case that the popover needs to be converted to a dialog instead, so allowing a popover to be used for adding new address.

> Oh, I missed the primary/preferred distinction. Wouldn't it be best to avoid
> having that extra notion? That is when the user changes their preferred
> address, it's the primary address in the account info that gets updated.
> That's pretty much the whole motivation for Bug 714643. It might be that
> some more work needs to be done on that bug to prevent things exploding when
> the primary address does change (the GMail login used, for example), but
> that's well worth doing. I'll have a look at it.

I use my university id (a semi-random number) to connect to its email servers, and my email address there is of the form oskar.viljasaar@. If we change the primary email field in the account's config, would we have a way to retrieve the original email address? I'm just thinking it might still be worth keeping around, just in case it would still be needed somewhere else in Geary's code.

To that effect, I was thinking it might be best that in the config there would be:
- the "primary_email" field which would not change throughout the account's lifecycle
- an optional "preferred_email" field pointing to one of the addresses in the alternate_emails field

That's the difference between your IMAP/SMTP login and your account's email address. On services like GMail and others the login and email address are the same, but more traditional or single-domain services often use different values here - E.g. "joe" and "joe@example.com". Geary already supports this distinction however, so it's not a problem.

It might be a bit weird changing the primary email address when it also gets used for the login, but hey - if that's what the user would like to do then we should let them.

Anyway check out the patches I just added to Bug 714643. It replaces the AccountInformation::email property with ::primary_email, which can indeed now be changed*.

[*] - Claim completely untested, patches may explode when poked.

Hmm, one other thing that might be good to fix here, or at least keep in mind, is that Geary should allow specifying alternate display names for alternate addresses, as well as just the address itself.

So my primary email might be "Michael Gratton <mike@example.com>", but I might also want to be able to send email as "Example.com Support <support@example.com>".

The same basic display ListBox approach can still be used, but this would mean that when adding addresses, two text entries would needed - name (prefilled from the account info's real_name) and address.

In that case we'll have to find a way to write those alternative names in geary.ini.

Maybe something to the light of having a second list in geary.ini, exactly as long as the "alternate_emails" list would be, with every name in the list going together with the address at the same position in the alternate_emails list?

I had a thought on how to present this to the user in the edit pane: we could just keep all of the UI we have right now, the only change would be to make the email address field editable.

That way, we could add and remove mailboxes through the "Additional email addresses..." popover, presenting a list of mailboxes with the primary one having a checkbox next to it. Editing the selected/primary mailbox's name and email address could then be done in the add/edit pane without having to open the popover.

This actually simplifies the interface: if the user doesn't want to use his default email address at all, he can directly replace it with another one without having to go through the process of adding an alternative email address.

Created attachment 331534 [details]
Screenshot showing the UI

I think this looks better!

Deleting the selected/primary account would set the next account as the primary one. If there's only one account, the delete button would not be shown.

I guess adding a new mailbox in the popover would result in something similar as what happens in the region & language panel, because we'd have to show two entries if we also want the name to be set per mailbox. I think it would be a bit more complicated to get it to look good if we want to do it in the list (transforming the add button into two entries). I can try to do it anyway, to see how that would look like.

Created attachment 331535 [details]
Mockup - also show the name if possible

The good news is that since AccountInfo is already using RFC822.MailboxAddresses for the alternative addresses - so if the names are set on them they should already be getting saved and loaded.

Hmm, I do like this idea of just continuing to manage the primary email directly in the account UI. However now I'm also wondering if something like your original suggestion is better - use a labelled button, but using the "flat" style class (like in Contacts) so only on mouse over does it fill out and look like a button.

Since there's still a few design issues to be resolved, I'd like to do a bit more work on the UI mockup SVG in Bug 714104 so the UI changes can get nailed down once and for all and and we can then just implement it.

Specifically we need to be able to compare the two approaches above (edit primary in add/edit pane and separate button for alternatives vs. having a flat button and doing it all from the popup), and also comparing using a Popover vs. a Dialog. These then can then be evaluated against the use cases we have and compliance to the HIG and common GNOME app conventions to see what the best approach will be.

These are the use cases I have in mind:

1. Change primary name & address to a new address
2. Add an alternative
3. Remove an alternative
4. Edit an existing alternative name & address
5. Set an existing alternative as the primary
6. Edit primary's email to be the same as an existing alternate email
7. Edit alternative's email to be the same as the primary email

1-3 would be required, 4 & 5 are optional but would be good to have, and 6 & 7 are undesirable and should not be possible. Have I missed any?

If you want to take a stab at the SVG for this before I get around to it next week, feel free. The gnome-mockups-resources Git repo has some handy templates.

I've just created a new wip/ux branch in git, with a WIP mockup for this is available in the ux/accounts directory of that branch, or here: https://git.gnome.org/browse/geary/plain/ux/accounts/email-mockups.png?h=wip/ux

There's a little bit more work to do on it, but so far Option 3 seems like the way to go, since there's only one level of nesting of dialogs. Use case #4 and #5 is handled fine, and #6 and #7 aren't possible, which is good.

Option 1 either suffers from two levels of nesting, or #4 is not possible, it does not handle #5 and anti-use cases 6 & 7 are a problem.

Option 2 also suffers from two levels of nesting to make #4 is possible, use case #5 is solved for the Popup editor at least, and anti-use cases 6 & 7 are a no problem.

On general, using a Dialog for editing (Option A's) instead of Popups (Option B's) means we can easily add avatar and signature editing in the future, however they need some work to handle use case #5 still.

What do you think? Feel free to update the SVG in ux/accounts with other options if I have missed anything out.

Just FYI I just discovered the HIG has some guidance for using a popover for this, under Custom Values at https://developer.gnome.org/hig/stable/drop-down-lists.html.en

Fixed on master by https://gitlab.gnome.org/GNOME/geary/merge_requests/71