Meanwhile the Thunderbird Addon is no longer maintained and usable.

Ok, I'll create new merge request soon. Thanks.

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.

Hello Daniel,

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 :)

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.

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.

well if limit of the PimItem.id comes into the game we need a subqueries, anyways.

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).

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:

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?

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.

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.

In T8408#237431, @brenthuisman wrote:

@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.

Hi Konrad! This may be a pre-requisite for T645, but it is not directly related to it.

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.

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!

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.

@knauss Did any development occur? On NLNet I see the project is still at 'Open' status.

Marked as Solved as per https://phabricator.kde.org/D29604 and https://invent.kde.org/pim/akonadiconsole/-/merge_requests/1 were accepted

This fixes the Agent sorting.

Me get funding from nlnet to work on this. The rough ETA is to finish this in June.

In T9416#228559, @kondzio wrote:

Daniel, I think I have finished preparing my changes. How will we process this further? Should I send my changes someone to review?

Thanks,
Konrad.

Daniel, I think I have finished preparing my changes. How will we process this further? Should I send my changes someone to review?

any updates?

Hi, sorry, I mussed have missed the notification.

Hello Daniel. Could you tell me what photo or description should we display for a group contact ? Which phone number and email address should be displayed for single contact ? home or preferred ?
See the screenshot in the attachment, I prepared an example solution. Are you sure that we want to display two smaller pictures one below the other? or the appearance on the screen is acceptable in your opinion?

Hi! Sure :) The underlying data model is Akonadi::ContactsTreeModel which is subclass of Akonadi::EntityTreeModel. Thus, if you have a QModelIndex, you can use the data() function to retrieve data for the Akonadi::EntityTreeModel::ItemRole, which gives you the Akonadi::Item which holds the contact itself: KContacts::Addressee

const auto item = index.data(Akonadi::EntityTreeModel::ItemRole).value<Akonadi::Item>();
if (!item.hasPayload<KContacts::Addressee>()) {
    // error handling
    return;
}
const auto contact = item.payload<KContacts::Addressee>();

Daniel, I want to prepare a solution for this task, but I can't find a way to get an email address in added delegate inside paint event when the email address column is hidden. I tried to get it from the model but it only contains the columns that are visible in the GUI. Can you help me with this?

Separate keyrings is indeed what I meant, it's what at least some clients do. I don't think gpg supports multiple keyrings though, so you'd need to include a lib.

In T8408#197809, @brenthuisman wrote:

Regarding the externality of the PGP client: a few tools I know use an internal (OpenPGP.js I am sure) library when set to Autocrypt mode. Enigmail as of version 2, when in the default easy mode, did not appear to store keys in the external client (when autocrypt is enabled) but somewhere internal (you can find openpgp.js in the Enigmail sources). The pEp mail client's the same, and a new Thunderbird client 'AutoCrypt' that does not offer a regular PGP mode also won't use any client you may have installed.

@knauss Thanks for your elaboration.

The task with released with Application 18.12.

The task with released with Application 18.12.

The tasks were released with Applications 19.04.

[spam comment removed by sysadmin]

In T8408#191334, @brenthuisman wrote:

Encouraged by the Junior label and heliosmartins reference, I'm looking into the Autocrypt spec to see if this is something I could do (I do not know what the Junior label specifically means or how it was determined). Adding a header to all outgoing emails seems fairly straightforward.

There are some mockups with some qml in the hig for an address book: https://hig.kde.org/components/navigation/toolbar.html https://invent.kde.org/websites/hig-kde-org/tree/master/HIG/source/qml/addr. This can be used for inspiration.

Encouraged by the Junior label and heliosmartins reference, I'm looking into the Autocrypt spec to see if this is something I could do (I do not know what the Junior label specifically means or how it was determined). Adding a header to all outgoing emails seems fairly straightforward. For retrieving mails, which was classified as 'advanced' in the task, I'm trying to flesh out the work needed a bit more. I have zero Kmail or KDE coding experience (a bit of C++ I do). The Autocrypt spec does seem quite well worked out such that I only have to think about the best integration into Kmail.

Whishlist bug report about autocrypt support:

As Thunderbird and k9-mail (Android) support autocrypt it would certainly make things a little easier when using email encryption and making it a little easier isn't a bad thing.

The tool is up to date and working as far as I am aware, but any bug reports or suggestions for additions would of course be welcome.

@mlaurent could you please add a reference to commit(s) that implemented this for future reference?

Thank you for all your work so far!

I don't have much time now, so if someone want to clain this task instead you are welcome.

Hello, I very busy lately. I hope I will have more time to finish this task, during the holidays.

There's Prefs::createNewColor() in eventviews/src/prefs.cpp, looks like that might be it?

Sory for the delay, I distro hopped from arch to openSuSe and I have some trouble with building from source with openSuSe (libkleo and some other dependencies don't want to build). And I also have trouble finding where the color is generated (the calendar is generated in korganizer:src/akonadicollectionview.cpp, but I have trouble finding when and where the color is set).

In T9420#166886, @ngraham wrote:

BTW, here is the official Breeze color palette: https://hig.kde.org/style/color/default.html

BTW, here is the official Breeze color palette: https://hig.kde.org/style/color/default.html

Ok I will look into that :)

@ognarb uh, sorry, I haven't seen the notification about your last comment. Yeah, going for some more pastel color to better fit Plasma/Breeze color theme would be nice. Maybe the entire default color generator could be improved - I honestly don't know much about where the colors come from in KOrganizer :-)

@dvratil Do you have some other improvement suggestion? I was thinking about changing the default color to a pastel green color (#BAED91) but otherwise I don't know that can be improved anymore.

I was looking at this task to learn how akonadi work and akonadiconsole crash directly after choosing a instance. It is a know bug? Should I create a bug report?

I would say let's treat the HiDPI problem as a standalone issue, the painting code should probably take font metrics into account, instead of hardcoded arbitrary constants :)

@repinc interesting, but I don't have a HiDPI screen to test. I read in the internet that using QRectF,QPointF instead of QRect and QPoint should improve the situation. So I'm changing most of the occurence of QRect and QPoint. I also found out that the item height is hardcoded in function of MonthCell::topMargin to an height of 18px, but I have not idea how to access the pixel ratio.

@dvratil here is the screenshot

@dvratil Ok, it's very much VIP but I have some visual D16377

@ognarb That sounds like a good idea: you can use it to get information about background and foreground colors and calculate some reasonable color palette from that.