[digikam] [Bug 218297] SETUP : Database location under control panel doesn't match when using database-directory command line option [patch]

[Simon]

https://bugs.kde.org/show_bug.cgi?id=218297

--- Comment #14 from Simon <freisim93 at gmail.com> ---
(In reply to Glenn Washburn from comment #13)
> I would expect the configfile to have the "database Name*' properties
> changed if you change the database path in the configuration dialog.  Am I
> reading correctly that you're saying otherwise?  If not, then I'd agree that
> it would be misleading.  My point though, is that misleading or not, if the
> user does change this he probably has a good reason to.  Put another way, if
> you don't have a reason to change your database path, then you won't change
> that field and everything works fine.  Its comes down to a question of
> allowing more flexibility for unknown use cases at the expense of a user
> shooting themself in the foot, or to not allow this.  I'm in favor of less
> paternalism.  But personally, I'm not that adamant either way because even
> if that field is disabled, I can copy the database directory to a new
> location and have --database-directory point there for the same effect.

You need to discern between two scenarios:
(1) Database location given with --database-directory.
(2) Database location taken from configuration file (i.e. now
--database-directory command line option).
Obviously for (2) the path is still configurable and will be saved in
configuration, otherwise what would be the point. However if you specify the
path at runtime (1), which in general is a different path than in the config,
you cannot modify the path in the configuration dialogue. Arguments as stated
before: Either overwriting the configuration path, which is not visible in (1)
or just changing the database location at runtime, which is not persistent
after restart, is suboptimal. If a user specifically sets the database
directory with a command line option, I don't see why he needed to change it in
the GUI, just restart and use another command line option.

> As for the cases where --config* is given a directory or the parent dir does
> not exist, I would suggest exiting with an error, instead of trying to
> recover.  If the user specified this option clearly they do not want the
> default config file, so why default to giving it to them?  If you agree with
> this logic, then I'd suggest using --config, exiting in either of those
> error conditions, and doing what I suggest initially otherwise.  What do you
> think?

Sounds very sensibly actually.

-- 
You are receiving this mail because:
You are the assignee for the bug.