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

Dan Leinir Turthra Jensen admin at leinir.dk
Mon Feb 3 11:51:14 GMT 2020


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
> 
> See below for investigation results:
> 
> Am Freitag, 31. Januar 2020, 00:14:19 CET schrieb Christoph Feck:
> > On 01/30/20 13:53, Friedrich W. H. Kossebau wrote:
> > > as found out by discussion on irc, a good solution for everyone relying
> > > on
> > > the default GHNS storage as provided by KDE is to just not hard-code any
> > > value for ProvidersUrl, but leave it out and let KNewStuff default to
> > > what is built into the KNewStuff library as current value.
> > 
> > Does it work with all KNewStuff 5.x versions? Otherwise, the required
> > KF5 version would need to be bumped where this change was made.

  We'll need to adjust the documentation to ensure the below holds true

<snip> 
> So seems there is some flaw in the design of Attica when it comes to the
> concept of platforms: having a different provider for a non-Plasma platform
> does not make sense to me.
> This needs to be rethought, also when it comes to defaults.

  Entirely correct, that is definitely an ommission. While Attica's 
qtplatformdependent does lack functionality like the persistence layer for 
adding, removing, and disabling/disabling providers, it should most definitely 
be returning the default provider as the documentation says it can be expected 
to. So, just posted a patch[1] which makes it do so (instead of a simple, 
empty list).

[1] https://phabricator.kde.org/D27123

> Too sleepy to think further now. And this best is sorted out by KNewStuff
> developers :)
> 
> Cheers
> Friedrich


-- 
..dan / leinir..
http://leinir.dk/




More information about the Kde-frameworks-devel mailing list