The password field should also be validated to not be empty.

We'll also need to figure out how to do form validation in general:

• We can validate as you type or as the form is submitted (for some content both may be desirable)
• We probably want a per-field feedback that tells the user what is wrong.
• We might need additionally need a per-form feedback if multiple fields in conjunction had to be validated.

The icons don't need to be exported as exported files are what the system needs from the flatpak (such as the application icons). The theme icons are only needed inside the flatpak, so not exporting is correct. I guess this is just an annoyance of flatpak.

This adds no additional value until we have signatures, gpg-key or have a service that supports sending with additional email addresses.

Actually, drafts don't seem to be synced by the composerview.

for the log view it makes sense as a primary action. I experimented a bit with copy buttons everywhere but was not happy with the result. how well does keyboard navigation work with context menues?

We're setting the backgroundcolor and font by now. Both is hardcoded, so that's not great.

Works! Thanks

Included libcurl: https://commits.kde.org/flatpak-kde-applications/fe4e0b49001d46c26dd1246cc2376d80caaffe5f

In sink. If its not somehow conflicting with the existing libcurl,, then sure.

Where are we using libcurl? Would it make sense to build it separately in Kube's flatpak manifest?

kube_otp links against QGpgme, so that should be fine.

Sorry for the *very* late reply. This might very well be obsolete as we no longer depend on the external mimetreeparser. If it is still relevant feel free to adjust the patch as required and ship it.

We fixed this a long time ago.

• ⋊> ~ on master ⨯ dnf repoquery --requires --resolve kf5-kmime-devel 15:57:28

tlp RPM packages 4.8 kB/s | 257 B 00:00
Fedora 25 - x86_64 - Updates 4.5 MB/s | 24 MB 00:05
Last metadata expiration check: 0:00:09 ago on Wed Jun 28 15:57:49 2017.
boost-devel-0:1.60.0-10.fc25.i686
boost-devel-0:1.60.0-10.fc25.x86_64
kf5-kdelibs4support-devel-0:5.34.0-1.fc25.i686
kf5-kdelibs4support-devel-0:5.34.0-1.fc25.x86_64
kf5-kmime-0:16.12.3-1.fc25.i686
kf5-kmime-0:16.12.3-1.fc25.x86_64

• ⋊> ~ on master ⨯ dnf repoquery --requires --resolve kf5-kmime 15:57:59

Last metadata expiration check: 0:00:20 ago on Wed Jun 28 15:57:49 2017.
glibc-0:2.24-8.fc25.i686
glibc-0:2.24-8.fc25.x86_64
kf5-kcodecs-0:5.34.0-1.fc25.i686
kf5-kcodecs-0:5.34.0-1.fc25.x86_64
kf5-ki18n-0:5.34.0-2.fc25.i686
kf5-ki18n-0:5.34.0-2.fc25.x86_64
libgcc-0:6.3.1-1.fc25.i686
libgcc-0:6.3.1-1.fc25.x86_64
libstdc++-0:6.3.1-1.fc25.i686
libstdc++-0:6.3.1-1.fc25.x86_64
qt5-qtbase-0:5.7.1-16.fc25.i686
qt5-qtbase-0:5.9.0-1.fc25.x86_64

This is now resolved and the messagelib dependency is gone entierly.

We need an animation for a new item, an animation for removed items (message sent), and we need to keep showing the outbox while the animations are still running.

We have the logview for this.

This will be resolved with: https://phabricator.kde.org/source/kdav/browse/dev%252Fnokio/

This will be available in kimap 0.2

Potential key backup strategy:

• Derive the key from a sufficiently long password using an algorithm such as PBKDF2 (See enchive --derive: https://github.com/skeeto/enchive)
• The key can then be regenerated from the same password and as such it can be:
  • backed-up a notebook
  • copied to other devices by copying it manually (or using a barcode scanner)
• While backing up that passphrase will again result in a potential weakness (depending on where you store it), it might also provide an easy & secure way for backup and transfer.

For key resolution see messagelib/messagecomposer/src/composer/keyresolver.h
For encryption/signing see messagelib/messagecomposer/job/*encrypt*