Modularize an envelope view by introducing a stack of "view filters".
Example uses:
- html email can have a view on top of it that is plain text conversion
- selecting and viewing text/* attachments is just appending a new filter at
the stack
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Tests / Test on ${{ matrix.build }} (linux-amd64, ubuntu-latest, stable, x86_64-unknown-linux-gnu) (pull_request) Successful in 12m35sDetails
Tests / Test on ${{ matrix.build }} (linux-amd64, ubuntu-latest, stable, x86_64-unknown-linux-gnu) (push) Successful in 14m2sDetails
Flag and tag modifications are now somewhat typed better, and the
frontend applies them on its own on success. This means that if you set
an unseen mail as seen but it was already seen in the backend, you will
see the change locally. Previously it would remain unseen.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Instead of showing the nondescript tab names in the tab area,
use Subject or To: data from the draft in the composer and a subject
from the thread entries.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
For large threads, this would result in a lot of futures being created.
The user just wants to read one entry, not all of them. So prioritize
the open entry and some of the latest ones as an optimistic
pre-fetching.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Dialogues handled Esc themselves, which meant the event didn't bubble up
to their parent to let them know they should remove the dialogue. This
commit fixes that.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
There's no need to clone MailViews when opening them in new tabs,
just initialize new ones with the same metadata. That saves us the
trouble of implementing Clone for all related types.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Tests / Test on ${{ matrix.build }} (linux-amd64, ubuntu-latest, stable, x86_64-unknown-linux-gnu) (push) Successful in 8m9sDetails
When adding contacts from an envelope view, its hash/id/key was a random
Uuidv4, so it was always possible to add a contact again and again with
no limits. Now, the id is calculated from the hash of the email address
and display name, preventing duplicate additions.
Note that the hash algorithm is not supposed to be stable across
versions, meaning that in the future the same contact might have a
different hash. This means a more sophisticated method for
detecting/disallowing dupes must eventually be introduced.
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
Guillaume Ranquet
Manos Pitsidianakis