Indended default behavior for Qt settings vs. command-line? #1903

Examples:

You can set -detachdb, which overrides the Qt setting. When opening the Qt settings dialog it shows the real state of -detachdb.

But you can set -lang, which (when opening the Qt settings) does NOT show real state but instead the stored Qt setting.

I guess we should specify what is the intended behaviour without the need for special casing. Should perhaps command-line options permanently SET the Qt settings? Same for the proxy stuff I'm working on, I can't yet figure out what is the best way ... @laanwj I hope you can contribute :). What do other devs think?

The intended behavior is (we've discussed this before):

• command line options temporarily override QSettings for that run (ie, command line takes precedence for effective settings, but do not permanently set the qsetting)
• options GUI shows currently effective settings, no matter where it came from
• when you change an option in the options gui and save, both the effective setting and the qsetting change

(in the above, command line can be read as bitcoin.conf; you can regard bitcoin.conf as a command line that will be passed for every invocation)

I hope this clearly defines the intended behavior.

I know we had talked about that ;), but I had some problems left, let me explain.

What if I pass a proxy via -proxy, which is then displayed in favor of a possibly stored proxy value from QSettings and press OK (save), it will certainly overwrite the stored QSettings, is this behaviour okay for you? I was a little unsure, but now think that is fine ... at least it would be a massive headache to get a check in for this, as OK is always active.

The next heavy thing is when using -tor with -proxy, where the former overwrites the second. I then need to implement the same checks used in the core for Qt, which results in duplicated and nearly identical code. But I'm only starting to think about that part, so no hurry.

Are you fine with updating all missing options to your proposed default behaviour? As I said at least the language setting is missing there.

I think the ideal solution would be to implement a "dirty" bit per setting so that only settings that are actually touched are written when "OK" is clicked. But in the meantime, the current behavior (clicking OK saves the currently viewed values to QSettings) is fine...

*The next heavy thing is when using -tor with -proxy, where the former overwrites the second. I then need to implement the same checks used in the core for Qt, which results in duplicated and nearly identical code. *

Please don't duplicate any checks. That's extremely error-prone, especially in an area such as argument handling that changes all the time.

I don't understand why you'd need to. We only need the currently effective settings and can always query those from the core. No need to repeat any work.

If you don't find a way to do this without introducing ugly/duplicated code, better to not do it at all. There's enough other issues that need to be solved on our bug tracker...