Compose dialog close should just save [$15]

[Danielle Foré]

Instead of having a separate save button and prompting me if I want to save when closing, just save. We should "always be saving" and it looks like we are. So it's weird to have an explicit save.

Prompting to discard on close seems odd. If I wanted to discard, I would have clicked that button. Since we're always saved there's nothing to lose by closing so why are we asking to save? It's weird.

[Danielle Foré (danrabbit)]

https://www.bountysource.com/issues/30589756-compose-dialog-close-should-just-save

[Robert Roth (evfool)]

FYI: based on the code, email drafts are saved each 10 seconds, and on close no save happens. I guess this should be changed than - to save on close - to avoid loosing at most 9-10 seconds of work if closing. Is that right?

[Robert Roth (evfool)]

Also, what should happen if saving the draft fails, what is your suggestion, to avoid potentially loosing a full mail? Should there be a warning or something? (Maybe this is out of scope of this bug, but worth discussing)

[Danielle Foré (danrabbit)]

Yes, we should explicitly save on close in addition to the timed auto-save. It might be worth looking into the method by which Scratch auto-saves which I think is a bit more sophisticated than a timer.

Hrm, I'm not sure under what circumstances saving would ever fail... do we have a precedent for that? Any other app that has a fail case for saving?

[Ralph Plawetzki (purejava)]

The compose dialog always prompts you when closed. This pop-up dialog has an additional third option 'Keep', when the body of the email has been modified - Keep saves the draft.

As soon as the body in compose dialog changes, the email gets saved ten seconds later.

The two buttons "Close and Save" and "Close and Discard" are shortcuts to prevent the pop-up dialog from coming up.

> FYI: based on the code, email drafts are saved each 10 seconds, and on close no save happens.
There is an additional third option to save changes on close - see above.

> Also, what should happen if saving the draft fails, what is your suggestion, to avoid potentially loosing a full mail?
A GLib.message gets written. This should be sufficient.

> It might be worth looking into the method by which Scratch auto-saves which I think is a bit more sophisticated than a timer.
As soon as you change the body of the draft for the first time, the drafts gets saved every ten seconds from then on.

The two buttons "Close and Save" and "Close and Discard" are important when a new draft gets composed inline, hence not detached as these are the only ways to close the draft. In Mail composing happens always detached, right?

[Ralph Plawetzki (purejava)]

Assuming that drafts are always composed detached, from my point of view we have two possible ways to go from here:
1) remove the two buttons "Close and Save" and "Close and Discard" and simplify the pop-up to only show up and ask if the body was changed before (so don't show up when there is nothing to save)
2) remove the two buttons "Close and Save" and "Close and Discard", remove the pop-up and when the compose dialog gets closed either close it without saving the draft (in case the body did not change) or close it and save the draft (in case the body has been changed)

My personal taste in this is to go with option 1, as I like pop-ups, preventing me from accidentally forgetting something :)
What fits best into the elementary look and feel?

[Danielle Foré (danrabbit)]

When you're composing inline, clicking away (selecting another message or sidebar item) from the draft in any way is the close action.

I don't think we should remove the explicit discard. There should be a way to "cancel" and immediately delete the draft.

I do think that asking to save is something we should be seeking to eliminate across the OS. Auto-saving is something that users should expect. You're never asked to save in Gmail, for example.