The intent of the --database-directory command line option is to allow for multiple independent DK databases and instances. However the current usage of the application wide config file, digikamrc, is at odds with this. The digikamrc file can not be specified on the command line, so there is only one per user, even though there may be multiple digikam databases. Since the digikamrc file has some settings that definitely should be different per digikam database instance, such as the "Database Settings", there should be a way to specify a different digikamrc file when selecting a non-default database instance. I suggest that the directory specified via --database-directory be the directory where the digikamrc file is expected. This would be a very simple to fix by modifying the KSharedConfig construction at https://cgit.kde.org/digikam.git/tree/app/main/main.cpp#n150. If commandLineDBPath is null do what is done now, otherwise do construct like: KSharedConfig::openConfig(commandLineDBPath + QLatin1String('/digikamrc')) This will make digikam instances truely independent and should have the added benefit of fixing bug 218297 as well.
Git commit e0f1d3dd4056deff260f673788af2cc6f9df1033 by Simon Frei. Committed on 18/03/2017 at 15:00. Pushed by sfrei into branch 'master'. Add --config option and fix --database-directory option When database dir is specified at command line, the correct path is displayed in the configuration widget, but the input field is disabled. Related: bug 218297 FIXED-IN: 5.6.0 M +2 -1 NEWS M +39 -4 app/main/main.cpp M +2 -2 libs/database/utils/dbmigrationdlg.cpp M +10 -1 libs/database/utils/dbsettingswidget.cpp M +2 -1 libs/database/utils/dbsettingswidget.h M +3 -0 libs/settings/applicationsettings.h M +10 -0 libs/settings/applicationsettings_miscs.cpp M +2 -0 libs/settings/applicationsettings_p.cpp M +1 -0 libs/settings/applicationsettings_p.h https://commits.kde.org/digikam/e0f1d3dd4056deff260f673788af2cc6f9df1033
The above commit introduced the --config command line option. To set the database dir and config file to the same path, you can specify both options.
I think to fix this and provide a better user experience a small change should be made. The idea is that specifying --config is very likely if you are specifying --database-directory. So it would be nice to have a per-database-directory config file default. It makes sense that this would be in the same directory as specified by the --database-directory option. This is a pretty trivial change and I don't see any downsides. However, there are downsides to not changing this. My worry is that by sharing a config file, I might change a setting when using one DK database instance that will affect another database instance without my being aware of it, until its too late. Here's an scenario. Suppose I have one DK database instance, call it A, managing a set of photos that I want the XMP metadata written into the image and another DK database instance, call it B, where I want them written as sidecar files only. Since I'm a photographer and not a DK developer, I don't know how DK configs are stored. I might even guess wrongly, that they are stored in the digikam4.db file. So I don't realize that to not shoot myself in the foot, I need to have two separate config files. By default, the default config will be shared (bad default in this case). So supposing I setup instance B first, then A, then when I start adding tags to B, the photos in B will be modified, not what I was expecting. I suspect there are a lot of use cases like the above for different config settings. It seems to me that the best course of action would be to default to unique default config file when using --database-directory. There should be no fallback to the global default config file when --database-directory is given. If the user really wants to use a different config file path, perhaps sharing with another DK instance, they can do so explicitly. Bottom line: sharing config files is dangerous and should not be default behavior. The logic should be that if no --config is given, DK should first check for digikamrc in the directory specified by --database-directory, and if it does not exist should create a new one with default values. This would get DK another step closer to having photo collections that are easily re-locatable. I'm changing this back to "UNCONFIRMED" because I don't think this issue was really resolved.
Ok I see your point and I completely agree, this is not an issue of implementing, but of what behaviour do we really want. I am happy to change it once we reach a consensus. I will explain my point of view, but I am aware that it may be skewed due to "knowing the inner workings": In my opinion the behaviour should always be the least surprising. We have both --database-directory and --config (I assume that anyone who actually uses command line arguments is aware of this). For me the simplest and clearest is, when both have just one purpose. With your proposal --database-directory has the side effect of also changing the config location, which is (still, my impression) not directly obvious. Database and configuration being separate entities is common for many software. My intended use case: I have two collections, one on the laptop and on a network share. The databases are also stored on the laptop and on the network share respectively. I want digikam to have the same behaviour no matter which database I am using, so I share the config between the two. About your use case: Information is always stored in the database. You can only select whether you want to store it in image metadata/sidecar files as well. Therefore I don't really understand your example, unless A and B manage the same set of photos in the same location. But that would mean having different information in the image metadata and the sidecar in the same location, which seems very wrong to me in the first place (?).
In my example I was making use of the checkbox config option labeled "Write to sidecar files" in the Metadata pane of the configuration dialog. Once selected, a select box become enabled, where one of the options is labeled "Write to image and to XMP Sidecar". This option will modify the data of image files. So my constructed scenario was over two disjoint image sets, one where you want the image data modified and one where you didn't. I was attempting to show how using a shared config you could get into a situation where you end up modifying the image data in the image set that you did not want to modify because you had changed the setting in DK while using the other dataset. If you are unaware that that config is stored in the shared config file, as opposed to the database, you might not realize that it had been changed for the other image set that shared that config file. Basically it would appear as though someone had changed that setting without your knowledge and you might not discover this until DK had started to write to your images. And if that's your only set of image (bad practice, but I doubt that uncommon), then you've just irreversibly modified your originals. I hope that makes it a little more clear. I take your point about the non-obviousness of my suggestion, and I agree that generally options should not modify other options. It can be confusing. I think to help alleviate that a short sentence in the --database-directory help text could say something like "This option changes the default config to be in the given directory." I think what makes this issue critical is that DK can modify your data without you realizing it because of a non-obvious sequence of events. I'm concerned with anything that might modify the database or image files in a way that the user was not-expecting and which can not easily be reversed. My example was a case where the images were modified, but I believe there's a case for modifying the database when using the Maintenance tool and syncing the image metadata to the database. It could be overwriting data you didn't intend if you're not checking the Metadata settings every time (because say you don't think you need to because you didn't change it in this instance). After looking at the config options a little more, I don't think there's a lot of areas where this problem exists. Its mostly related to the the Metadata pane. For most of the settings, its not so consequential if the value changes without the users knowledge. I think my suggestion is the most conservative one to take. If the user gets annoyed that they have to change the same config option for each DK database instance, they'll look into using a shared config. Its annoying and extra time spent, but I think that's better than potential data loss. As to your example, I think its a very valid use case. I just don't think it should be the default. Also, considering that users of the --database-directory option will have been using the user global config file. It might make sense to copy that file (if it exists) to the --database-directory, and then use it. This will effectively break the shared config behavior that currently exists, but will minimize the impact by keeping the expected the config values. Since, we've had the shared config be the behavior when using --database-directory since its implementation (I presume), I wonder if anyone has been hit by this? But we likely would not even know this was the issue because the user might just think this is DK corrupting things.
Below are three emails concerning this issue posted to the developer mailing list. Apparently I wrote quite a few comments to bugs by email which never reached the actual bug. Sorry if I spammed the mailing list with tries to get it to work (I didn't). On 24/03/17 04:32, Gilles Caulier wrote: > Simon, > > I agree with Andrew. Point 2/ is more logic in this scénario. > > Note : Why this story is not fully in bugzilla file ? Somebody has > responded directly by mail to the bugzilla notification and the file is not > updated as 377587 <https://bugs.kde.org/show_bug.cgi?id=377587> comments... > > I recommend to backport missing comments in bugzilla to not lost full > story. > > Gilles > > > > 2017-03-24 1:00 GMT+01:00 Andrew Goodbody <ajg02@elfringham.co.uk>: > >> My vote is for 2) - always do what you're told and only what you're told. >> Give as much control to the user as possible, do not do unexpected things. >> Using a different config and/or creating a new one is very unexpected. I >> see no reason to assume the config would be colocated with the database, >> that's a very strange idea. >> >> Andrew >> >> >> On 23/03/17 11:48, Simon Frei wrote: >> >>> Thanks for the clarification, I get your scenario now. So it is a >>> trade-off between no side-effects and data safety. I still think that a >>> user using the command line options should be aware of the difference >>> between config and database and therefore be in charge of using >>> sensible/safe options. However planning for the DAU is also a good idea. >>> >>> I would like to hear what Gilles/Maik/Mario/... think about this. >>> Recap: The question is which of these options is favourable (arguments >>> in the comments above): >>> 1. Set config to the same directory as --database-directory. If no >>> config file exists there, create a new one/copy over the default one >>> (still respecting --config if given). >>> 2. Always use the default config unless --config is given, also with >>> --database-directory. >>> >>> >>>
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.
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
Hi Glenn and happy new year, Can you check if problem is solved with digiKam 7.5.0 pre-release bundle available here : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
@Glenn digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
This is the list of CLI option with digiKam 8.0.0: Usage: digikam [options] Professional Photo Management with the Power of Open Source - A KDE Family Project Options: -h, --help Displays help on commandline options. --help-all Displays help including Qt specific options. -v, --version Displays version information. --author Show author information. --license Show license information. --desktopfile <file name> The base file name of the desktop entry for this application. --download-from <path> Open camera dialog at "path" --download-from-udi <udi> Open camera dialog for the device with Solid UDI "udi" --detect-camera Automatically detect and open a connected gphoto2 camera --database-directory <dir> Start digikam with the SQLite database file found in the directory "dir" --config <config> Start digikam with the configuration file "config" "--config" is present here and solve this entry. Gilles Caulier