*** Bug 457902 has been marked as a duplicate of this bug. ***

The proxy stuff is KIO specific and KNewStuff does not use KIO for fetching the data. This is by design to avoid such a large dependency.

I fear this is a WONTFIX.

I find it to be a tragic shame when we can't fix bugs and re-use our own code due to bureaucratic restrictions or fear of adding new internal dependencies.

Isn't the average software using KNewStuff pretty much guaranteed to have KIO installed as well? I don't really see what the problem is here.

Dan also had a quite strong opinion on that, because it means that the KnewStuff code library will depends on lots of stuff in the KDE stack.

Please also see the message from the KCM:

>Not all applications will use this proxy setting. In particular, Firefox and Chromium or anything derived from them, or anything using  
>QtWebEngine - which includes Konqueror using the WebEnginePart, Akregator and Falkon - will not use these settings. Some applications 
>may allow the proxy to be configured in their own settings.

TBH this feels like just another place where the settings do not apply - in which case I'd rather question the usefulness of the KCM in systemsettings.

(In reply to Alexander Lohnau from comment #4)
> Dan also had a quite strong opinion on that, because it means that the
> KnewStuff code library will depends on lots of stuff in the KDE stack.
I just don't understand why this is a problem. We have the code, why not use it?

> TBH this feels like just another place where the settings do not apply - in
> which case I'd rather question the usefulness of the KCM in systemsettings.
I agree and am in favor of removing it, because it's terribly misleading right now.

>I just don't understand why this is a problem. We have the code, why not use it?

If an apps wants to use KNewStuff, we do not want to include tons of other stuff like KIO and consequently the dependencies it has. For KF6, we are trying to reduce the inter-framework dependencies. Using KIO for a very rare and in lots of other cases broken feature is just not worth the headaches.
Such large dependencies also make the deployments of apps more heavy, especially for Windows builds or AppImages.

If we were to say KNewStuff is part of Plasma I'd completely agree with you. However it is a frameworks and used by various apps.

I get it, but I 'd like to make sure that if we cut ourselves off from the ability to fix a bug for policy reasons, we're doing it to fix other actual problems and not theoretical problems.

What's an example of an app that currently uses KNewStuff but not KIO?

The reason for not using KIO is pretty simple: While KNewStuff3 (the widgets bit) can pull in widget dependencies without issue, KNSCore and KNSQuick should not, and including KIO ends up pulling in a requirement on KXMLGui. At least, that was the case when we originally made this decision (and wrote that code) a couple of years ago. If KIO's core "just get me this file" is now available without pulling in the huge dependency chain, then sure, there's no problem. Perhaps this changed with the recent KIO Workers, ehrm, work? But, in short: KIO isn't the problem, introducing a hard dependency on qwidgets to a qtquick module is.

I looked today and it seems like maybe KIO isn't actually using it anymore?

src/widgets/CMakeLists.txt:251:ecm_generate_pri_file(BASE_NAME KIOWidgets LIB_NAME KF5KIOWidgets DEPS "KIOGui KIOCore KBookmarks KXmlGui Solid" FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR ${KDE_INSTALL_INCLUDEDIR_KF}/KIOWidgets)
src/filewidgets/CMakeLists.txt:144:ecm_generate_pri_file(BASE_NAME KIOFileWidgets LIB_NAME KF5KIOFileWidgets DEPS "KIOWidgets KBookmarks KXmlGui Solid" FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR ${KDE_INSTALL_INCLUDEDIR_KF}/KIOFileWidgets)
src/filewidgets/kfilewidget.h:358:     * @deprecated since 5.66 due to no known users and leaking KXMLGui into the API.
.kde-ci.yml:20:    'frameworks/kxmlgui' : '@same'

Unless I'm misunderstanding this, I see that it's listed in CMake, but it doesn't look like anything in the code is actually using it.

An update here, i had a chat with Harald and David earlier, who suggested that yes, the purposes we have for this code /should/ now be possible using KIO Workers, by simply telling the function to just not do any UI things (which we don't support anyway with the current code, so no regressions), which would allow us to only require KIOCore, and then not need any of the widget stuff at all for distributing or launching any applications (which is the main issue, since we can't sensibly introduce widget dependencies in pure qml apps). So, in short: It should be possible to get rid of the current implementation, in favour of KIO Workers, given a bit of effort.

Is there a workaround that allows people behind corporate proxies to use KDE features like "Get New Wallpapers", "Get New Themes" etc?

With "Get New Wallpapers" I get a "An Error Occurred" pop-up saying "Loading of providers from file https://autoconfig.kde.org/ocs/providers.xml failed".

I'm using Kubuntu with cntlm and that all works fine for apt commands so there's nothing wrong with my proxy. I have set https_proxy and http/s_proxy environment vars pointing at cntlm but that makes no difference.

If these "Get New..." KDE features don't use KIO slave (~/.config/kioslaverc) then what exactly do they use? If they don't use / support proxies at all that would be good to know.

Is there a workaround that allows people behind corporate proxies to use KDE features like "Get New Wallpapers", "Get New Themes" etc?

With "Get New Wallpapers" I get a "An Error Occurred" pop-up saying "Loading of providers from file https://autoconfig.kde.org/ocs/providers.xml failed".

I'm using Kubuntu with cntlm and that all works fine for apt commands so there's nothing wrong with my proxy. I have set https_proxy and http/s_proxy environment vars pointing at cntlm but that makes no difference.

If these "Get New..." KDE features don't use KIO slave (~/.config/kioslaverc) then what exactly do they use? If they don't use / support proxies at all that would be good to know.