| Summary: | Folder view properties are inappropriately considered state data, when they're more like configuration data | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | Justin Zobel <justin> |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | duha.bugs, kfm-devel, nate |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Justin Zobel
2024-02-25 06:08:48 UTC
Looks correct to me. The config changes are tracked in ~/.config/dolphinrc State changes are tracked in ~/.share/dolphin Anything in particular you think doesn't belong into ~/.share ? Indeed, what data are you talking about specifically? Sorting configuration data. e.g. sort by name, size, type, modified, etc. This is configuration information. Yeah, this feels more like configuration information than state to me as well. But it's a fuzzy line. I would argue they are state changes: This (like the show hidden file setting) are often changed unlike regular config settings that are only changed rarely. Example usecase where this would be annoying: You have script that checks for changes in config files and then backs them up. I am not opposed to this changing, just trying to show that there are reasons not to do this. Yeah I can see how it would be fuzzy but from my perspective I "configured" dolphin to show the folder how I want it. As for backups, it's simply a matter of changing the files you're backing up. Which is why restore tests are a wise thing to plan into backups. I guess the question is, if you checked all your configs into git, would you be annoyed if changing it altered the config file? That's the common use case that people who want a strict separation of config and state (or how they perceive them) are looking to support. |