| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
and forward the email via an extension api.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are many things going on here (perhaps a bit much for a single patch):
- When an attachment is of mime type "application/pgp-keys", a button is added to import the key to GPG
- When sending a mail and crypto is enabled (encryption, signing or both), the public key of the first private key found is sent as an un-encrypted attachment (T6994)
- The `mailcrypto.{h,cpp}` was, for the most part, rewritten
- Introduction of the expected monad, inspired by what was proposed for C++ [here](https://isocpp.org/files/papers/n4015.pdf), but not at all a strict implementation of this specification. We may want to add some more features of this standard later.
The rationale for some of the choices:
- I found mailcrypto a bit hard to edit to add new features, and a great part was commented code to prepare for the support the SMIME crypto format, which would (in my current knowledge) not be used for sending emails.
- One thing I found that may be missing in the code base was a standardized way of handling errors in C++ code. Since exceptions are disabled I think that the functional way is the way to go. After some research I found the Expected monad / tagged union / sum type, which seemed to suit the problem particularly well.
In the long run, I hope we would move the entire code base to use `Expected` to indicate if a function might fail.
Of course every choice made here is to be considered as a proposition for doing things / RFC, critics wholeheartedly accepted.
Reviewers: cmollekopf
Tags: #kube
Maniphest Tasks: T6994, T8147, T6995
Differential Revision: https://phabricator.kde.org/D11158
|
| | |
|
| |
|
|
| |
...via syntax highligher or search api.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement attachment-based forwarding.
Some notes:
- `loadAsDraft` was removed in favor of new enum `loadType` in QML, and callback based generic programming in C++
Reviewers: cmollekopf
Tags: #kube
Maniphest Tasks: T7024
Differential Revision: https://phabricator.kde.org/D10676
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is mostly to demonstrate how this could work with additional menu
entries.
|
| | |
|
| |
|
|
|
|
| |
Note that we can not easily integrate it with Label due to recursive use
of Kube.Label via the Button component. (Would be doable via dynamic
loading, but that stuff is a PITA to do).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Removed the manual currentIndex handling again as we seem to be able to
use the regular stuff now.
Additionally the listview is now resized if we don't have enough mails,
so the first mail is shown on top.
We can also move from mail to mail using keyboard navigation.
The mail highlight also serves as focus indicator for the conversation
view in general, and as such is cleared when loosing focus.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We also need it when the to: line is too long.
That leaves us with the case where the button does nothing because there
isn't anything else to show.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Still a bit obnoxious and doesn't really convey a whole lot of
information. Consider it a stub for now
|
| |
|
|
|
|
|
|
|
|
|
| |
While in a much more managable state it's still not pretty.
However, further refactoring can now gradually happen as we need to do
further work on it.
Things that should happen eventually:
* Simplify the logic that creates the messageparts (we don't need the whole formatter plugin complexity)
* Get rid of the nodehelper (let the parts hold the necessary data)
* Get rid of partmetadata (let the part handleit)
|
| | |
|
| | |
|
| |
|
|
| |
We'll need proper icons though.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
