Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote: > > I agree on the problem of QNAM's default, see also https://conf.kde.org/en/ > akademy2019/public/events/135 on that subject. > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote: > [...] > > Prior to now, i've taken the approach o

Re: Banning QNetworkAccessManager

2020-02-03 Thread David Edmundson
I updated: https://community.kde.org/Policies/API_to_Avoid Which had no mention of this. David

Re: Banning QNetworkAccessManager

2020-02-03 Thread laurent Montel
Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > I updated: > > https://community.kde.org/Policies/API_to_Avoid > > Which had no mention of this. > > David I think that you made an error "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, true); " D

Re: Banning QNetworkAccessManager

2020-02-03 Thread Johnny Jazeix
[...] > All of the places where we have actively hit this issue have already > been fixed (Marble and Attica come immediately to mind, not sure if > GCompris fixed their code). > I took a quick look and we use some code to handle redirection: https://github.com/gcompris/GCompris-qt/blob/master/sr

Re: Banning QNetworkAccessManager

2020-02-03 Thread David Edmundson
No, no. Please go the other way round and update the wiki to whatever working code you have. David

Re: Banning QNetworkAccessManager

2020-02-03 Thread Johan Ouwerkerk
On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote: > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > I updated: > > > > https://community.kde.org/Policies/API_to_Avoid > > > > Which had no mention of this. > > > > David > > I think that you made an error > > "networkAccess

Re: Banning QNetworkAccessManager

2020-02-03 Thread Volker Krause
On Monday, 3 February 2020 10:49:10 CET David Edmundson wrote: > I updated: > > https://community.kde.org/Policies/API_to_Avoid > > Which had no mention of this. Thanks for taking care of this! I'd propose a slightly different approach than the per-request all-or-nothing attribute mentioned i

New utility for easier breeze monochrome icon creation

2020-02-03 Thread David Hurka
Hi everyone, as indicated in https://phabricator.kde.org/D22617#502629, I have created an application “breeze-icon-cleaner”, which shall help with creating breeze monochrome icons. If you feel like testing/trying, it is now available at https://invent.kde.org/davidhurka/breeze-icon-cleaner. It

Re: New utility for easier breeze monochrome icon creation

2020-02-03 Thread Carl Schwan
Hi, maybe you want to join the efforts with Ikona since you both have the same goal to improve the icon creation workflow. https://invent.kde.org/kde/ikona Cheers, Carl ‐‐‐ Original Message ‐‐‐ Le lundi, février 3, 2020 2:52 PM, David Hurka a écrit : > Hi everyone, > > as indicated i

Re: WARNING: was bad recommendation (Re: Recommendation: drop ProvidersUrl entry to rely on default value)

2020-02-03 Thread Dan Leinir Turthra Jensen
On Friday, 31 January 2020 01:08:35 GMT Friedrich W. H. Kossebau wrote: > Hi, > > TLDR: removing the ProvidersUrl entry actually breaks things in non-Plasma > installations, so for now has to be hardcoded, using the non-deprecated > > ProvidersUrl=https://autoconfig.kde.org/ocs/providers.xml > >

Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 10:49 PM David Edmundson wrote: > > I updated: > > https://community.kde.org/Policies/API_to_Avoid > > Which had no mention of this. Many thanks for updating the wiki David. > > David Cheers, Ben

Re: Banning QNetworkAccessManager

2020-02-03 Thread Ben Cooksley
On Mon, Feb 3, 2020 at 11:51 PM Johan Ouwerkerk wrote: > > On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote: > > > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > > I updated: > > > > > > https://community.kde.org/Policies/API_to_Avoid > > > > > > Which had no mention of