This is done

Is there a reason for the wontfix designation? I've read this thread a few times and don't see one.

My suggestion would be to put the HTML/plain text switcher in the header, next to the other metadata. This could be done by for example showing a small list of possible MIME types, similar to the expanded sidebar in Claws Mail (but obviously a lot friendlier).

code for that is here https://invent.kde.org/pim/akonadi/-/merge_requests/28 but I'm too unfamiliar with Akonadi to review it

okay now we habe gpgconf support to enable/disable this. So this can be closed. Unfurtuantelly no way to close them anymore ;(

possibly fixed in https://invent.kde.org/frameworks/kdav/-/commit/bf6628ff1da1661a6485a2199d2222611e1b2ae5

In T14768#271239, @ndavis wrote:

It's just unclear what you need design help with. The videos show the current state, and it seems like it's not ideal since I can't understand any of it, but I don't know what to say or think beyond that. From my perspective as an inexperienced user, the ideal experience is that I don't even have to think about keys. It would only be something programmers and sysadmins would be concerned about. Emails would simply be encrypted when I want them to be. Maybe even by default without me being aware of it, similar to how https is everywhere by default on most important websites. I understand it's not as simple as that, otherwise encrypted email would already be far more common.

In T14768#271218, @knauss wrote:

@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.

As a first step I want to get improve the situation when sending an encrypted message. I want to remove/replace/improve all the dialogs that pop up AFTER pressing "send". I think a user should in best case not click "OK" at any other dialog after pressing "send". The user should have information BEFORE pressing "Send", if they wants to send it under specific circumstances.

@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.

@knauss: be aware that if the EARN IT anti-encryption bill passes, your efforts will all be for naught, as mail providers will begin refusing encrypted mail outright. Please spread the word!

It's currently not clear from the task descriptions what your goals are. I have next to no experience with encrypted email, but I know that PGP has a lot of built-in complexity that can be difficult to abstract away (part of why it isn't used by most people). Maybe someone else in the KDE VDG has more experience with encrypted email, but I don't know anyone in particular who does.

Hey VDG team, As the title tells you: I want to improve the current workflow of encrypted mails in KMail. At the moment focusing on the sending part of it. I need input from VDG about how to improve the current situation.

Moved to https://invent.kde.org/frameworks/kdeclarative/-/issues/1

Meanwhile the Thunderbird Addon is no longer maintained and usable.

Very cool :)

I started doing it a while ago: https://invent.kde.org/pim/kmail-account-wizard/-/merge_requests/2. I will try to resume the effort soon...

The reason for the complexity in the current header code is that this is a performance hot path. The heavily polymorphic design however isn't really suited for that, and thus we have dirty tricks in there like removing the vtable from the private class hierarchy.

@vkrause: you may have input on that?

@vkrause: any input on that?

@vkrause: maybe you either can give some input here?

Thanks. Nobody told me it broke a unittest and I didn't notice, indeed. I think kdepim's unittests are ... lacking supervision.

Broke the unit test introduced before in D8884 though, the part which does

QVERIFY((orderProxy->flags(firstRowIndex) & Qt::ItemIsDropEnabled) == 0);

in FavoriteProxyTest::testReordering()