For now we just save drafts and try to avoid crashing.

login name and email address are now separate fields. Separate loginnames for imap and smtp is very unlikely to happen in the UI, but would be doable anyways by editing the configuration files.

We already have a basic editor and support for lists is doable on top of what we have.

This has been solved by removing the button.

So; the lmdb assumption that pid's are unique simply no longer holds with pid namespaces. I suppose this could be seen as an lmdb bug.
I'm also not sure how well the whole separate process for synchronizers works if we were able to start multiple flatpaks. The sockets would have to be shared, and then each synchronizer would just live on in the sanbox of the kube process that started it...

I pushed the fix to master.

Tiles before adjustment.

A trial with a lowered title + screenshot included on top (positioning could be improved a little still).

No image

Design experiments

There does not seem to be any way to override auto-key-retrieve programatically => documentation issue.

And the main problem with that seems to be "keyserver-options auto-key-retrieve" in gpg.conf. Without it things are much more responsive it seems.

The main bottleneck seems to be signature verification and decryption.

https://github.com/flatpak/flatpak/issues/1859

And this is what geary does (I am not proposing that we should copy this behaviour in any shape or form):

For reference, here's how a persistent search bar looks.

Here's an attempt with a translucent button that get's a bit more opaque on hover

It looks better live than in the gif, but:

First version:

A downside of dimming/focusing part of the application is that only that part is really usable during the search. This shouldn't be a problem for maillist + conversationview, but if we do the same for the folderlist you have to finish the search to be able to view the contents of the folder properly. Not sure how problematic that will end up being.

That was already fixed.

This might be a flatpak incompatibilty.

This seems to be the EAGAIN error code that is returned from some operation that lmdb does from mdb_txn_begin

• mdb_reader_pid (via mdb_txn_renew0) is doing some fcntl calls.
• sem_wait is being called (via LOCK_MUTEX -> LOCK_MUTEX0). EAGAIN should only returned from sem_try_wait, so this shouldn't actually be a source.

A more useful variant of the backtrace:

We now start an extra gpg-agent with a fixed pinentry to work around the problem.

Another thing to put in the “expert imap account” setting would be that the used e-mail address and log in are not necessarily the same. For example, I get e-mails to the same IMAP server on both my private address and my FSFE address, but neither are the actual username for the server.

They are used to partition the events into the right day of the week (like before)

Ported to gpgme

Output of the !analyze command from windbg

0:037> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

This has been integrated.

I collected the relevant patches (I hope): https://github.com/cmollekopf/lmdb/tree/0.9.22_sparsewin32

Register color in Kube.Colors
Follow attribute naming conventions

As long as we check gpgme error codes we should be fine:

Upon further inspection it seems like the "CBC/CFB Gadget Attack" can only be executed if an attacker intercepts a message, tampers it appropriately and then forwards it to the recipient.
In such a case the attacker can potentially retrieve the plaintext of that specific email. One potential risk could be that with enough content the private key could be guessed, which would of course be much more severe.
In any case, this is about targeted attacks only I think.

I don't have commit access (or so I believe), would you commit the changes? Thanks.

I thought about that as well but haven't come up with a good name so far. Kube Mail would be tempting right now of course, but limiting ourselves to mail is really not what we're aspiring to be, so not a great name in the long run I think. Kube is about communication, collaboration and organizing/structuring (traditionally called Personal Information Management and Groupware) and I have yet to find a catchy name for that. Ideas welcome =)

How about instead of a full rename a "tweak" of the current name? Maybe something along the lines of 'Kube Mail'? What do you think?

Yeah I've noticed that.