KIO currently has KRecentDocuments as well, just to add confusion to the mix. I certainly wish it would disappear or move down in tierness, it's not KIO related.

https://invent.kde.org/frameworks/kservice/-/merge_requests/44 deprecates KPluginInfo::fromKPartsInstanceName

Proxy: it's also not clear to me what the difference between the "Auto Detect" button there and the "Detect proxy configuration automatically" is.

Right, actionSlotMap() can be deprecated, actionSlotMapPtr() is the replacement.

Ah! I misunderstood. Yes indeed, targets would be fine.

I don't see how that would work, it just shifts the problem to "which version of ECM is installed on this system?".
You'd do find_package(ECM) in kmyapp, and hope it finds the version that defines the KF version to the one that this code is compatible with? Too much indirect magic.

I'm wondering if this is really a good idea. Both for Qt and KF.

The locale encoding is always UTF-8 on Unix and some "more local" locale (latin1, koi8-r, etc) on Windows.
So what you described can only happen on Windows. Still bad, of course, for reading existing text files. But the user base isn't exactly as big as on Unix, for KDE software. This is just very surprising overall for Qt on Windows. In the JIRA task you linked, Thiago initially said "QTextStream needs the ability to select between UTF-8 and the locale's 8-bit charset". But you seem to say this didn't happen?

Just a thought: should we fork QTextCodec as KTextCodec and make our lives simpler in the process?

CI runs things in a sandbox, there are no translations installed that are accessible to kf5 tests.

I agree, a similar effort is happening in Qt as well.

OK, you're a bit of a "special case" then. Most developers who want to make their first contribution to KDE, do not start by reading Qt sources (nor Marc's 2010 article, lol). Most people initially treat Qt as a black box, relying on its documentation only.

Thanks Alex, you rock.

I'm sure you learned about pimpl yes, but not about Q_D/Q_Q macros and Private classes inheriting from each other...

So this is basically the same as https://phabricator.kde.org/D29136 except that D29136 gives priority to the non-deprecated variable. Any reason against going with D29136 after all?

No, that's all that's missing indeed.
https://lxr.kde.org/ident?_i=BrowserHostExtension

Maybe I misunderstood your line about I haven't seen the d-pointer dereferenced before (at all?), usually one accesses the private class via the d-poitner, to me that's the same.

You can't use d->something() when using the Qt macros, without first doing Q_D() which declares a local variable d from the result of d_func().

OK. IMHO that's a nice side-effect but not a good enough reason to use Q_D everywhere. It confuses C++ developers who haven't read Qt code before, raising the barrier of entry for contributions.
To save allocations in case of inheritance it's worth it, but just for const correctness, I'm not fully convinced.
Just my 2 cents.

How is this "an issue with usefulness"? It's just part of the syntax. If you forget the const, the compiler reminds you.

The main point of the Qt macros is to have the Private of the subclass inherit from the one of the base class, so that a single allocation is necessary.
The syntax of the Qt macros is to encapsulate that.

Agreed about both.

In T12225#245844, @ahmadsamir wrote:

I couldn't readily see where konqueror got to the KHTML part

We should keep BrowserInterface after all, it's now used by WebEnginePart too. I'll retitle the task.

Yes but only because they are hooks for KHTML.

"a qt5combat module" << excellent typo ! :-)

I'd say keep it consistent with BrowserApplication. If it no longer does the '!' thing then don't either. Creating a local desktop file keeps things easier on the consumer side.

In KF6 (where we can drop compatibility), the information about --noclose would be only in the KCM, not in ktoolinvocation any longer.

Hmm, this isn't what I said, I think.

You could use the same trick as BrowserApplication:

• if it starts with a '!' it's a literal command
• otherwise it's the ID of a desktop file

Update on the config vs state thing: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/4 https://invent.kde.org/frameworks/kconfig/-/merge_requests/33

kwidgetsaddons/src/kmessagebox.cpp line 374:

const QDialogButtonBox::StandardButton result = QDialogButtonBox::StandardButton(guardedDialog->exec());

KMessageBox::warning[...], which ends up calling QDialog::exec(), is very much "sync" API and very much an open door to event loop re-entrancy. They have the same issue as the other two.

As I said, it was used to define extra columns.
It appears that it was used in konqueror before konqueror's file management views were replaced with Dolphin's.
See http://www.davidfaure.fr/2020/konq_listviewwidget.cc

It's also used to define extra columns.

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.