https://bugs.kde.org/show_bug.cgi?id=377587
--- Comment #7 from Glenn Washburn <developm...@efficientek.com> --- You summarized it well, "a trade-off between no side-effects and data safety". While I agree with Andrew in principle, I don't in this specific case. I think we're trading one unintuitivity for another and going from benign to dangerous consequences in the process. My suggestion would be less unintuitive if we have a comment in the help about the side-effects, while I think it would be harder to explain the unintuitiveness of sharing a config to the user. There is perhaps a third way. Take the "dangerous" settings in the config and move them into the database. There is already a "Settings" table where there are some config settings (settings that could be global, though determined to be , accurately so I think, more useful on a per database basis, eg. "databaseImageFormats"). I don't particularly like this option because it makes it harder to copy those settings to another database if so desired. I think there may be a difference of vision for DK here. I want DK to be an app that manages sets of photos, potentially many sets, where each set is pretty independent. The defaults should be easy, intuitive, safe. It feels like DK was developed to be used as a single database instance app, which has been hacked to allow other databases to be used. If you're transferring your collection to another computer, you'd want your config to go with it because it contains parameters that define how you work with your photos collection. I suspect most users would have to dig to even figure out where the config file is located. I think it makes sense to keep the config file with the database files. Perhaps ultimately the global config should only store the most recently used database (eg. only "Database Settings"), but that would probably be another bug report. -- You are receiving this mail because: You are watching all bug changes.
