A unittest would be useful too, especially if we then refactor the loading to use KIO jobs.

In D29871#676150, @rrosch wrote:

I didn't have an assert before though, should I replace the if statement with a Q_ASSERT then?

A bunch of fixes got reverted. The dead code is back. The assert is gone. The docu improvement is gone....

I can't really approve a half finished feature that is undiscoverable.

Well, if you insist, but this is how cruft just adds up. Will you -- or someone else -- remember to actually remove this weird entry from desktop files when implementing something better?
I just don't see how it belongs there. To make this actually available to users, you'd have to ship two desktop files "Home" and "Home with hidden directories shown"? Urgh.

In D29871#675959, @rrosch wrote:

BTW we have moved to gitlab for merge requests :-)

Argh. So how do I do it now?

Users don't create or edit desktop files ;)

The commit log explains the what but not the why. Can you give more details about the use case for this? At first sight it smells like overconfigurability (given that the user can already request that hidden files are shown, more globally).

Only if you can find a way to change BatchRenameJob in a binary and behaviour compatible way. And then it will be a dual-headed thing with two modes of operations, awful. All this sounds to me like much more trouble than writing a different job.

Done.

Not fully sure. I thought it was corruption of the glimpse databases, but every tuesday they get deleted and recreated, AFAICS.

https://lxr.kde.org/search?_filestring=&_string=KAboutData looks much better now.

Here are my findings.

One thing that used to work better, was that I was able to get email when the cron job fails.
But now it says
"
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

In the repo where your git push fails, what does git remote -v say?

OK, Qt min version increased: https://invent.kde.org/network/konqueror/commit/a6def18fba4958e0c5a105fd0d8507baeca78d92

Good idea to check the default webengine. Just in case :)

In D26342#675180, @aacid wrote:

In D26342#675164, @sdepiets wrote:

I don't think that's a regression, in the previous behavior you could try to set any language to proofread, it would always auto-detect "Bonjour" as French, thus the "Tools / Spelling / change language" had not effect if autodetect was enabled at system level (while autodetection should be an application or even case by case decision).

@stefanocrocco if it makes your life easier I'm fine with konqueror requiring Qt >= 5.12 (currently the CMakeLists.txt says 5.9, but KF5 requires 5.12)

This actually breaks language auto-detection for me in the KMail composer.

Sorry, slipped my mind.

In D26253#675054, @rjvbb wrote:

Implementing something Konqueror-specific in kwebkitpart doesn't really feel right though. I suppose that the konq: URLs are implemented by generating HTML code which is then sent to the engine; is there a reason why this would have to be done in the web kpart? That would also solve the problem for the other view modes (my build still shows KHTML, but also a fancy term for "kate" and okular).

The fix is to implement similar support for the about page (with konq: URLs) in kwebkitpart. Since you're the only person interested in kwebkitpart these days (AFAIK), feel free to go ahead and do that.

Done in https://invent.kde.org/pim/akregator/-/merge_requests/1

This breaks FreeBSD compilation. Please check: https://build.kde.org/job/Frameworks/job/kcrash/job/kf5-qt5%20FreeBSDQt5.14/17/

Done in https://invent.kde.org/frameworks/kcrash/commit/c315685f0e0920e8847afe12c97fbbe4653eb351

This question is still without an answer: "Can you explain how to trigger this crash in the first place? Which application triggers it?"

This commit seems to include the changes requested in the other review...

The changes you mention don't appear in phabricator.

Alternative solution: we port apps to libqt5keychain, which itself supports KWallet, gnome-keyring and libsecret (which I assume uses "secrets service").
See task T12219