CmdlineArgs: Add --rescan-library for rescanning on startup

[fwcd]

This adds a small convenience flag for rescanning the library on startup without changing the settings.

[Swiftb0y]

Code LGTM, though I'm interested why you think this is useful as a CLI option (as opposed to the menu button or the keyboard shortcut or the config option) in the first place.

[fwcd]

I'm looking into making my track import workflow more scriptable and rescanning the library is one step towards that.

My plan is to add an option for analyzing new tracks on startup in a future PR too, but since that will likely be more complicated both from an implementation perspective and perhaps more discussion-worthy, I've split out this PR (which was fortunately pretty trivial to implement since we already have the setting).

[Swiftb0y]

so you conditionally (depending on whether mixxx got called from your script or yourself) want to rescan the library?

Would it make more sense to have an overwrite for the config file so its not limited to this one setting?

[fwcd]

so you conditionally (depending on whether mixxx got called from your script or yourself) want to rescan the library?

Yes, exactly

Would it make more sense to have an overwrite for the config file so its not limited to this one setting?

That's an interesting idea, hadn't thought of that. Feels a bit more convoluted from a usage perspective, but would definitely be more general and I guess for scripts the reduced discoverability would be fine. Haven't looked deeply enough into the config mechanism to find out how complicated that would be to do.

[Swiftb0y]

probably not terribly as long as you don't need it it to do at runtime. The clang-tools have an option to overwrite the config as well as specific parts of the config (for example in clang-tidy via --checks), but thats probably not complexity worth delving in.

[fwcd]

I've had a quick look at ConfigObject. If we want to support overrides there, we'd probably have to store overrides in a separate map, to avoid accidentally committing the overrides to the main config. There are probably some pitfalls with this, like e.g. how we handle the corresponding checkboxes etc. in the UI. Should they display the overridden values? Is it unexpected if they still change the underlying value in that case (and don't do anything until Mixxx is relaunched without the override)? Maybe the cleanest solution would be to disable them if overridden, but that would likely require a large number of changes across the UI.

I feel like there's a fair bit of complexity involved to make this "non-surprising" and am wondering whether it's worth the effort. Any thoughts?

[Swiftb0y]

I feel like there's a fair bit of complexity involved to make this "non-surprising" and am wondering whether it's worth the effort. Any thoughts?

Yeah, lets avoid that for now. We can re-evaluate once we introduce more flags.