• Fix broken patch

• Update messagelib dependency

• Increase messagelib version

Thanks for the changes. One more change/optimization, please.

If I may add my two cents here, I agree with David that introducing a plugin for a plugin is a bit over the top. Whats the issue with contributing your backend into libkscreen upstream instead? If there's any code that could be shared between KWayland backend and your new backend, you can create a small static library (basically reusing most of what you've already done). Otherwise you are basically forcing libkscreen to accommodate a single usecase for your fork, and the community has the right to push back on that as it makes things more complicated for them just to make live easier for you.

It would be helpful to describe why your removed the two test cases

collectionForId is a good name, I think.

• Add method to check if the feature is enabled

@mlaurent ping, I need this as a prerequisite for D29629 :)

Nice, thanks!

You could still do it but it's a bit more complex: you can use Item::storageCollectionId() to get ID of the real parent collection. You would then need to use the ID against EntityTreeModel to resolve the /actual/ Collection with displayName populated.

• Address comment reviews

Seems OK to me.

Nice job, just some suggestions for improvements...

• Address review comments

• Address review comments

• Fix wrong default for showing the main window

Re documentation: It's partially documented here: https://techbase.kde.org/KDE_PIM/Akonadi/Development_Tools - strace is not documented as far as I can see
Re kdeinit: Akonadi does not use kdeinit at all

Thanks, Till.

In D29030#663591, @knauss wrote:

Can you explain me how you get strace output for akonadi?

I think @dfaure has touched exactly on this issue before.

• Remove duplicate include

Thanks. Yes, please land this on 20.04 branch.

Would switching back to TCP on Windows (using QTcpSocket) solve this issue without the explicit flush? I'm also playing around with replacing the entire Qt socket code by ZeroMQ that apparently works pretty well on both Windows and Linux, so we could drop all the non-blocking wait-for-data socket code on Windows...

Thanks a lot, Glen!

Could easily be put into some FindUtils.cpp file or so, doesn't need to be in the TextEditFindBarBase just because it's a baseclass.

Looks good, just one nit pick - you can fix it before committing, I don't need to review it again.

The ETM patch looks OK, but if the ETM is owned by the destroyed widget, then it likely won't work 100%.

If the code is shared, why not put it into a shared function that both editors can call? As fat as I can see, the function would only need the QTextDocument and the mFindWidget as inputs and would return the number of replacements made, which you can then use to emit the signal.

• Fix signal/slot connection

Hmmm, one option could be to add QEventLoopLocker into ETM to keep QApplication alive until the job in ETM has finished?

Thanks for the patch. Land it to the release/20.04 branch, please.