We need to decide on what KIO is.
Some people think "if I don't need kioslaves, I shouldn't have to use KIO".
But another line of reasoning is "if you want to do any sort of file-management stuff with URLs, files, dirs, mimetypes, then KIO[Core] is what you want". KFileItem, KFileItemListPropreties, KFileItemActionPlugins... this all fits into this definition.
Where else would one put KFileItem and KFileItemListProperties?

Merged. Please reopen this (or just paste the comment) if you find more.

See T11821 for the similar task for KDirModel.

This is already there in kdirmodel.h
Here's a MR for doing the same in kfileplacesmodel.h: https://invent.kde.org/frameworks/kio/-/merge_requests/130
Any other model that needs this?

--> https://invent.kde.org/frameworks/syndication/-/merge_requests/5

The second architecture seems better/simpler.

In D29299#676447, @pino wrote:

In D29299#676446, @dfaure wrote:

In D29299#676445, @pino wrote:

One of the primary goals of KF5 is to be useable by other applications not written by the KDE community (I actually know quite a few).
As such, it's not hard to imagine a cmake-based application that uses Qt and GNUInstallDirs [with qmake going away this will happen more and more], and one day it wants to use one of the frameworks. At that point, it shouldn't be forced to switch to ECMInstallDirs. Therefore I definitely see value in keeping the two things separate, as long as we keep making things easy for what is the most common case for us: using both.

Sigh. I know this, I never, ever, ever, and let me say it again, never, forgot about this.

In D29299#676445, @pino wrote:

I asked for actual valid use cases when using the new variables first would break, and I still got none. There is a limit to how much you can keep broken code working... assuming such broken code exists. I don't think there is any of this such situation, as ki18n_install() is basically used by KF sources that use ECM already, with marble being the only exception (and even that, marble won't break).

(to remove some confusion: the previous comment had the wrong link and should have said "Abandoned in favour of https://phabricator.kde.org/D29299" -- but now it's reopened anyway, as an alternative to D29299)

@pino Other than the fact that you think D29136 is "good enough", do you have any concrete objection to this version?

https://invent.kde.org/network/konqueror/commit/cd6364a2c8a5362c49145204de4eebeff1e4185c

Ah, I forgot I had to land your patches manually.
I'll do it now (already resolving a few conflicts...)

@broulik can we remove this task from the dashboard?

https://lxr.kde.org/ident?_i=KDBusConnectionPool&_remember=1 says everything was ported away from KDBusConnectionPool, good job :-)

Were you using the Markdown/text editor or the full blown office one?

My experience with editing files on share.kde.org yesterday: constant conflicts, can't rename the file, *lost my changes*, can't give out a link to the file (it lists the directory), can't copy/paste the filename at the top when opening the file. Next time I'm using the wiki.

So, to be sure, I continue with this patch, adjusting the unittest to the new hash -- and no change required in akregrator?

OK, fair point, putting the task back onto the board ;)

More details:

This is not as easy as I thought it would be. When used without QXmlInputSource, QDomDocument simplifies whitespace-only CDATA sections.
This patch: http://www.davidfaure.fr/2020/port_syndication_away_from_qxmlinputsource.diff
leads to a failure in autotests/atom/atom10_entry_content.xml which can be narrowed to
-id: #hash:aff2c4358030579d2c3dcea6e92b40fe#
+id: #hash:a359558b397d24593c3b55afb85d173a#

What's deprecated is only QXmlInputSource, QXmlReader/QXmlSimpleReader and associated classes (QXmlEntityResolver, QXmlAttributes...).

Removed from the KF6 board (I can't find how to fully delete a task)

Right, there is no task here anymore.

The main problem I see is the KRecentDocuments integration.

I agree, this is too vague, and therefore not actionable. @knauss do you want to make the task more targeted, or should I (somehow) delete it?

QDomDocument won't be deprecated after all, so we can forget this IMHO.

Right, @stefanocrocco maintains the WebEnginePart for konqueror, @rrosch worked on the sidebar, other people ported it away from deprecated API, and I review contributions.
So konqueror is still around.

Turns out QDom isn't deprecated after all, so maybe this task isn't applicable anymore.

It's more than "a handful" though.
I repaired lxr after noticing many desktop files were not being indexed, and it shows that this is used by:
kup, calindac, baloo_file, konqy_preload, kmix, rsibreak, klipper, kalarm, korgac, and kgpg
That's a large number of apps to adapt to toggling the Hidden key at runtime, no?

Thanks :-)

No, we determined that the trader language wasn't the best way to write C++ code.
ktraderclient was mostly written as a debugging helper. I suggest to strip out the constraint functionality from ktraderclient.

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/