One suggestion for this change:
Instead of exporting a method that takes no parameters and always loads from configuration file, why not make a new method with the implementation that takes in a given KConfigGroup. That way unit tests can pass in a KConfigGroup setup appropriately without having to create a normal configuration file in the user's home folder (ie use a temporary file). They can also configure the KConfig to not cascade/use the global configuration so they are isolated from the environment.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 3 2020
Aug 7 2019
LGTM. Regarding the test, if we want to get this change in asap due to the security focus I can submit a follow up patch re-adding it.
Jul 8 2018
Jul 7 2017
+1 LGTM. Before submitting, can you poke the usability people about this change please? If they are also happy, then it's got a ship it from me.
Apr 25 2017
LGTM! Thanks for working on this.
Apr 23 2017
Excellent! Could you add 4 more rows to the tests, to ensure a path without a folder (ex. systemConfigLocation + "/test.desktop") works correctly? Once that's done, it's a ship it from me.
Apr 19 2017
In D5502#103322, @wbauer wrote:In D5502#103316, @mdawson wrote:Can you please add some unit tests for this, to ensure it doesn't break in the future? I think just three extra tests, one for a desktop file in a config directory, one in a data directory, and one present elsewhere would be enough.
Yes, I'll try.
Though it will take till tomorrow I suppose...
+1 This definitely looks like the correct fix.
Feb 20 2017
Ship it!
I agree, this can't be used so removing it from the API can't hurt anything. Just to be sure, let's take this change for the next release, but not change KConfigBackend' API/ABI until after the next release. If anyone complains about KConfigBackend missing before then, we can just re-export it easily. Otherwise this can always come back in a (ABI) different form if this ever becomes worthwhile. Does that sound good to you?
Feb 4 2017
Dec 1 2016
LGTM!
Sep 10 2016
Feb 19 2016
In D990#18933, @kfunk wrote:In D990#18925, @mdawson wrote:In D990#18917, @kfunk wrote:In D990#18912, @mdawson wrote:LGTM.
Out of curiosity, why is the QHash detaching for you here? Or is this just a general fixup found with a linter? Either way, I'm happy to take it :)
Well, we're calling QHash::find on a non-const variable -> QHash::find detaches internally. Showed up in a Callgrind run.
Right, but looking at this function it looks like the QHash shouldn't have multiple copies which should prevent a detach in the first place. Thus I was curious what work load triggered the copies causing the detach.
Indeed, you're right. I just noticed it calls QHash::detach, but doesn't reallocate (-> non-shared container). This patch won't harm, though: constFind/constEnd is still faster, doesn't check whether the container is shared to begin with.
In D990#18917, @kfunk wrote:In D990#18912, @mdawson wrote:LGTM.
Out of curiosity, why is the QHash detaching for you here? Or is this just a general fixup found with a linter? Either way, I'm happy to take it :)
Well, we're calling QHash::find on a non-const variable -> QHash::find detaches internally. Showed up in a Callgrind run.
Out of curiosity, why is the QHash detaching for you here? Or is this just a general fixup found with a linter? Either way, I'm happy to take it :)