We've discussed this on IRC.

I'm not a big fan of adding yet another options source. The GUI already has command line, bitcoin.conf and QSettings - in that order of precedence. This has caused many complications and bugs in the past, especially during initialization, only now it seems to have cooled down a bit so I'm not really happy to stir the ants' nest again (we don't have a test suite for this part).

Remember this all has to be backwards compatible. We can't just drop QSettings support. If you remember 0.5.x, the client used to store GUI settings in the wallet. It took long enough until we were able to finally drop that functionality.

I'm happy that you're adding options to the GUI, but please don't couple it to this.

This doesn't change initialisation at all, it uses the same code as bitcoin.conf for that. For now, everything currently in QSettings remains in QSettings (although upgrading them wouldn't be very difficult or risky, it's not really an immediate goal).

QSettings is not really a good solution since bitcoind won't use it (I can't think of any use case where you'd want these kind of settings different depending on whether you use Daemon vs GUI).

I think I'm going to need to make this aspect of the design be take-it-or-leave-it. It seems more than reasonable to let it sit a while and get any bugs ironed out in LJR/Knots before tackling it in Core.

QSettings is not really a good solution since bitcoind won't use it

That's certainly a valid argument for using our own system instead of QSettings for core settings.

If you add a test suite that tests interaction between various parameter sources, as well as backwards compatibility, I'd feel better about this. I just don't want to introduce a new source of stress.

Conversation with @laanwj on IRC re settings enum: Goal should be to move this into util, not to introduce strings to GUI. Makes more sense to do it as part of RPC setconfig (#7289), rather than rwconf.

Agree with @laanwj that we should not couple additional GUI settings with the different persistent store file.

QSettings works nice and is platform independent, but – I agree – users might have problems to locate the file (to delete or inspect/change) and I agree that keeping all bitcoin related config file in the bitcoin-datadir would be good.

I don't have a strong opinion on that, one one hand, I would like the fact to keep all files together (would also be possible with setting the QSettings path [http://doc.qt.io/qt-4.8/qsettings.html#setPath]?), on the other hand, adding more code of that type (that needs maintenance) should be avoided.

@luke-jr: Are you interested to open a PR with just the maxuploadtarget GUI option? I think that one would be uncontroversial.

Needs to be closed or rebased. I think closing would make more sense since this seems to be controversial.

Not familiar with QConfig, but if it's Qt specific when it ought to influence bitcoind then I'd say the sooner it's removed the better. If this pull helps with that process then, utACK.

@luke-jr Can this pull include an example bitcoin_rw.conf file or is it parsed in the same way as bitcoin.conf? If the latter then why the new code to parse it (can't it use the same code used to parse bitcoin.conf)?

@rebroad bitcoin_rw.conf is parsed the same. The difference is that this file is modified by the code itself when the user changes options in the GUI, rather than needing to be modified manually by the user.

@rebroad Given that #7289 allows config changes during run-time - we might want to permit some of those changes to persist between runs - something like this pull (are there other options on offer) do seem to be needed - therefore ACK from me (unless a better alternative is coming along soon).

Closing for now because it seems to be controversial.