refactor: coreArgs, log is a persistent option, making it now optional - #9032

Just thinking out loud... this seems a bit weird. Why not just have no log arg means use internal logging? Why would anyone set --log=internal?

It gives you a way from the CLI to reset where the log goes. Otherwise you need to open the settings to change the setting after.

I see. It's still a bit weird though. I believe this is a symptom of having CLI args that persist, which is unusual and counter-intuitive.

If I understand correctly, --log currently persists into settings, which breaks the expected contract of CLI arguments. Users will expect command-line flags should act as ephemeral overrides for a single run, not silently rewrite durable configuration. This creates hidden side effects that are hard for users to track or reason about, and has created the problem you're trying to solve now.

The design is further weakened by overloading --log with two different meanings. In one case it is a file path, in another it is the special keyword 'internal'. A string argument should either represent a path or be empty, not a path sometimes and a reserved keyword at other times. This ambiguity increases complexity for both users and maintainers.

There are three potential ways forward:

1. Keep the persistence and let a bare --log write an empty string to clear the setting, which still leaves the problem of CLI mutating config -- this is my lest favourite as it's still not very intuitive, but it's a quick fix.
2. Drop CLI logging arguments altogether and require all persistence to be handled in config or UI -- this is the least expensive to maintain.
3. Keep CLI arguments but make them non-persistent, so they only override the config for the current run without saving changes.

The third option is the most consistent and least surprising. CLI args would remain a tool for transient overrides which is a common pattern, configuration files would hold durable state, and persistence would only happen when explicitly requested through config set or config unset. This separation of concerns avoids the confusion in the current design.

All our options in the core presist now.

1. That is way more akward so im gonna say no
2. The Gui is not and should not be a requirement to run deskflow.
3. means passing arg and not using the settings in the core (Replace CLI args with Qt settings file read in Core #8852)

Remember this ONLY will be for users directly using the core without the gui

Non of the CLI options are needed and we can tell ppl to modify the configuration file then re run..
we could even remove the mode and this can come from settings . basicly the only options needed in core are

• -h --help used to generate man and list valid options / use
• -v --version report the version (as used for man)
• -s --settings Settings file to use
• --setup todo , a cli wizard to configure w/o the gui

All other setting are only for configuration that would be otherwise handled by the core,

In the future we remove the --log option completely and write to a temp file for our log. this will be needed to inject the log into random GUI instances when #8879 will need this anyway (at least if we continue to show the log within the app , something i think we can also remove after #8257 )

• The Gui is not and should not be a requirement to run deskflow.

That's not what I'm suggesting. Editing a config file is trivial; no GUI required.

we can tell ppl to modify the configuration file

Yes, this is what I was suggesting.