@carewolf ported it away from QtScript, https://phabricator.kde.org/D23801

He also said, Qt disabled the use of libproxy back when libproxy linked to Qt4 (clashing with Qt5).
That was probably for reading the KDE proxy settings (!), which nowadays can be done by just using XDG_CONFIG_HOME | ~/.config and not linking to any Qt/KDE code...

The biggest problem is how to test all this...

libproxy does not link against Qt anymore, they use kreadconfig5 and friends to read the values. So using that should be safe.

libproxy does not link against Qt anymore, they use kreadconfig5 and friends to read the values. So using that should be safe.

That's what I wrote on the bug report as well: https://bugreports.qt.io/browse/QTBUG-52252

It's still disabled by default and when enabling it manually there's a huge warning in bold to not do that...

Actually KIO::ProxyScout has to be ported to something else, because QNetworkConfiguration is gone in Qt6, and there is no replacement.

void ProxyScout::disconnectNetwork(const QNetworkConfiguration &config)
{

// NOTE: We only care of Defined state because we only want
// to redo WPAD when a network interface is brought out of
// hibernation or restarted for whatever reason.
if (config.state() == QNetworkConfiguration::Defined) {
    reset();
}

}

https://codereview.qt-project.org/c/qt/qtbase/+/494754 for enabling it upstream by default

There's one thing in our proxy settings that libproxy doesn't seem to cover: The "Use proxy settings only for addresses in the exceptions list" settings.