feat: move settings.json to .config on unix-like systems

[lucaengelhard]

Description

Currently the settings are saved next to the program state files on unix-like machines. This PR moves the settings.json file so that it aligns with the .config convention.

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

• update get_settings_path so that it resolves to .config/RapidRaw/settings.json on unix-like systems
• added migration logic so that old settings.json are correctly transferred

Screenshots/Videos

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: Omarchy 3.4.1 (Linux 6.18.13-arch1-1)
• Hardware: NVIDIA RTX 4060, Intel i5-11400F

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

Old settings.json files are automatically moved. Maybe there should be a warning or popup that asks if the user wants the file moved?

Also the folder name is currently hardcoded in. That maybe should be changed?

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[lucaengelhard]

Maybe it also would be a good idea to separate things like lastFolderState into a different file, because that isn't relevant for the config and only store real settings data in the config

[CyberTimon]

Hi @lucaengelhard

On macOS the conventional config location is ~/Library/Application Support/, which is what Tauri's app_data_dir() already gives us. Moving to ~/.config there would break platform conventions. Should this only apply to Linux?

The todo!() when HOME isn't set will crash the app at runtime. Better to just skip the migration entirely and use the existing path in that case.

If the copy fails silently (the let _ = on the copy call), we end up returning the new path that has no settings file, so the user's settings just vanish with no indication of what happened. If the copy doesn't succeed it should fall back to the old path instead.

Thanks for your work!
Timon

EDIT:

Maybe it also would be a good idea to separate things like lastFolderState into a different file, because that isn't relevant for the config and only store real settings data in the config

Yes! This is a good idea. Let's track this after we completed this PR.

[lucaengelhard]

Thanks for the feedback! Tbh i forgot I also opened this PR. I will look into your suggestions

[lucaengelhard]

@CyberTimon I updated the code, but I'm not particularly happy with it. Maybe we should put this on the backburner for now as I'm way more focused on and interested in the general refactor of the codebase (#800 and #844)