Is there a reason for the wontfix designation? I've read this thread a few times and don't see one.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 5 2024
Jul 1 2023
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).
Apr 12 2023
Apr 2 2023
code for that is here https://invent.kde.org/pim/akonadi/-/merge_requests/28 but I'm too unfamiliar with Akonadi to review it
Oct 5 2022
May 19 2022
okay now we habe gpgconf support to enable/disable this. So this can be closed. Unfurtuantelly no way to close them anymore ;(
Mar 17 2022
Feb 19 2022
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.
Feb 18 2022
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.
Feb 17 2022
@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!
Feb 16 2022
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.
Feb 15 2022
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.
Feb 10 2022
Jan 17 2022
Meanwhile the Thunderbird Addon is no longer maintained and usable.
Nov 19 2021
Oct 28 2021
Oct 21 2021
Very cool :)
Oct 19 2021
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...
Sep 29 2021
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.
Sep 28 2021
@vkrause: you may have input on that?
@vkrause: any input on that?
@vkrause: maybe you either can give some input here?
Sep 24 2021
Aug 9 2021
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()
Aug 5 2021
Jul 23 2021
Jul 22 2021
I gave a try for KMail yesterday on Debian bullseye system.
Jul 4 2021
Apr 25 2021
Apr 14 2021
Ok, I'll create new merge request soon. Thanks.
Apr 13 2021
It would help, if you would summit a merge request on invent.kde.org: https://invent.kde.org/pim/akonadi/-/merge_requests
From first glance the patch seems fine. But we will look in more detail, if you summited a merge request, as it has a much better interface to give feedback.
Apr 12 2021
Hello Daniel,
Mar 30 2021
Mar 21 2021
Note:
Mar 16 2021
Mar 6 2021
Thank you Carl for looking into this! This task is probably the biggest porting blocker for PIM, I'm very happy to see we have a way forward for this now :)
Mar 2 2021
PoC MR: https://invent.kde.org/pim/kmail-account-wizard/-/merge_requests/2 There is still a lot to do but it seems the approach is viable.
I started the port in work/qml branch (https://invent.kde.org/pim/kmail-account-wizard/-/tree/work/qml). It is using KPackage for loading the wizards, so it will require updating all the existing wizards but since I was able to expose the existing SetupManager without much changes to the QML engine, it probably won't be that hard to port everything to QML.
Feb 10 2021
In my opinion approach with subquery is better because I made a small comparison with a similar query on "Employees Sample Database" from dev mysql site.
I used similar queries to ours, because I don't know how to do execution plan with estimating cost on the lower version of MYSQL,
but from what I see limiting set is done before doing JOIN and the final query cost is much lower than in the second case.
Feb 9 2021
well if limit of the PimItem.id comes into the game we need a subqueries, anyways.
Feb 8 2021
Makes sense that views don't optimize. I was hoping we could avoid scanning the large PimItemTable multiple times and just reuse the list of pim items in the flags/parts/etc. queries. I guess there's no fast way to do that without stored procedures (and creating a temporary table would be too expensive).
Feb 7 2021
I think I can handle it. Thanks for help.
@kondzio : yes that is what Daniel recommended, but a temporary view cannot be optimized.
I thought Daniel recommended creating a temporary view, because he wrote in his last statement:
"However, we could optimize this and create a temporary view with the filtered, limited results on the PimItemTable first, then use the view in the additional queries, then destroy the view again ".
It seemed to me it has sense because there is currently no functionality that the QueryBuilder class can use to nest a subquery in the main query FROM clause, unless I missed something.
But why create temporary views? No human is creating the queries. Views do not improve the speed in anycase. If you only construct a view for one request it only makes the resulting query nicer to read. But no speed improvement. I think the first idea of @dvratil for the query is fine:
Feb 6 2021
Hello Daniel,
I encountered another problem while working on this task.
How are we should creating a temporary view? from what I know MYSQL doesn't support temporary views.
Initially, I tried to create a view based on a query that returns the buildItemQuery function only if ItemFetchJob had a limit greater than zero,
and when it was no longer needed I removed it at the end of the ItemFetchHelper::fetchItems function.
Next I added the functionality which prepending id to the view name, because each connection/thread on the server may have a different limit at the same time, and I also added a mutex locking functionality when each new view is creating.
In this approach I see one potential risk in situation when exception occurs (e.g. closing connection by client) between creating and deleting view, then created view will never be deleted.
Can You help me how to deal with it? or maybe there is an easier way to do it?
Dec 12 2020
Nov 18 2020
Moving to invent: https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/20
moving to invent: https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/19
Oct 29 2020
that's a good point. I would say that adding a getter to QueryBuilder to get the mTable field and using that in QueryHelpers is a good design decision.
Oct 28 2020
background support is now on the way to enter: https://invent.kde.org/pim/messagelib/-/merge_requests/15
Hello Daniel,
Could You please advise me ?
The main problem for me with implementing these changes is that every function that builds its own query in ItemFetchHelper, for example buildPartQuery finally calls ItemQueryHelper::scopeToQuery(mScope, mContext, partQuery)
All these helper functions in ItemQueryHelper: scopeToQuery, gidToQuery, remoteIdToQuery, itemSetToQuery which generate additional where clauses have hardcoded table and column names for PimItem and are also used in many other places not only in ItemFetchHelper.
Sep 24 2020
In T8408#237431, @brenthuisman wrote:@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.
Sep 23 2020
Hi Konrad! This may be a pre-requisite for T645, but it is not directly related to it.
Sep 22 2020
Now I understand how this should be implemented, more or less. Daniel if You only answer my first question I think I could start working on it.
Sep 21 2020
Hello Daniel,
I would like to try to implement this task. Can this task be implemented separately, or is it somehow related to the task T645?
Do you have any information that would make it easier for me to start coding? because currently I have little knowledge about Akonadi.
Great work, Konrad! Many thanks for improving KAddressBook!
Sep 19 2020
Thanks, that was my first assignment and I'm pleased to be able to contribute.
really nice work :D
Hi Daniel,
It seems to me that changes for this task are finished.
Sep 12 2020
Sep 9 2020
Sep 8 2020
Sep 7 2020
Aug 19 2020
Aug 17 2020
Aug 14 2020
@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.
It seems that there are quite a few recent GPL-2.0-only files too, probably as a result of copy/pasting the license header, in particular in the autotests folders, so probably half of those files are "easy" to fix. The rest however is indeed going to be challenging.