• ⋊> ~ 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*

Received signal Received signal 7 BUS_ADRERR 7f0743402000
Received signal 7 BUS_ADRERR 7f073b4c9000

An "Inbox" view was suggested. This would likely become the start of the "Read" view. The idea is that you get a single list of things that you need to go through. The view would help triaging by grouping by certain heuristics that could be linked to actual importance:

• Are you addressee of the mail (or just in cc)
• Do you know the sender (is the sender in your addressbook)
• Is the mail from a mailinglist?

The plan is:

• No busy/error indicator on folder or account
• Single status text in status bar (perhaps with icon if useful)
• Progressbar next to status text for longer operations
• Progressbar on top of maillist (as maillist delegate so can be scrolled away from) for the special case of "I'm waiting for a new email and therefore I'm waiting until this becomes available.

Not sure about the above backtrace, but webengine requestinterceptor is the current cause for kube to not shut down as it should.

On a related note; the history/timeline could also be a place to visualize progress on an operation on top of the list. Perhaps as a way for for us to keep the hints fairly minimal normally, and if you must know there is still an interface that gives your more detailed insight (perhaps including downloadspeed etc at some point).

We'll likely ditch this in favor of a timeline/history view that also includes errors (for the time being anyways).

For longer operations a progress bar is something we should have, it's definitely useful. But if we show a progress bar then the busy indicator is redundant.

A likely addition to Soon:

• History/Timeline:
  • Shows sent mails, edited drafts, notifications, errors, .... A single time sorted list of things that happened. Can eventually become a place to undo stuff as well.

We'll likely start off with fulltext query only when connected to the server. Locally you can still filter by subject, sender etc.

As a second step we could start using the gpg key that we will setup with every account to encrypt credentials. This would serve as a portable, but kube specific keyring.

A likely candidate is the root "view", or the beginning of every stack, or perhaps even every page on a stack.