https://bugs.kde.org/show_bug.cgi?id=469862
Bug ID: 469862
Summary: Add named configuration "profiles" that can be
selected on startup
Classification: Applications
Product: digikam
Version: 8.1.0
Platform: Other
OS: All
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: Setup-ConfigFiles
Assignee: digikam-bugs-n...@kde.org
Reporter: michael2macdon...@gmail.com
Target Milestone: ---
SUMMARY
In Digikam it is possible to set the configuration location via a command line
argument. This feature has many important uses and is only becoming more
necessary (more about that below). I believe that it would be highly beneficial
to expand this feature to the GUI. Digikam needs an option in the preferences
window to create additional config files (called profiles) that can be selected
during startup to use different configurations and databases.
**Note: I am not sure if this fits better under 'Setup-ConfigFiles',
'Setup-Database', or something else. Change as you see fit.
OBSERVED RESULT
- Config location can only be set using the command line arg.
- Multiple configs require you to manually create additional desktop entries
with the desired config/database options if you want to launch them using the
GUI
- Windows with different configs are all treated the same (they are not
differentiated) so if you have multiple instances of Digikam open with separate
configs, they stack in the taskbar and are treated as the same program. This is
especially bad when you start opening dialogs and child windows of each
instance.
EXPECTED RESULT
Profiles can be added, renamed, and removed in preferences. Optionally, a
custom config location can be specified for each profile instead of Digikam
assigning it a location. On boot, Digikam opens the default config file and
reads a list of the added profiles. If there are no other profiles, it boots
normally. If there are one or more profiles, it provides the user an option to
select a profile to boot from (default, profileX, profileY, ...).
- The default config/profile stays in the same location as it is now (to
maintain compatibility) and is the master config that Digikam always relies on
to be there so it can fetch the rest of the profiles and config locations. (The
only change to the default config is that it will contain a list of the
additional profile names and config locations to call on when it initially
boots).
- The default profile is whatever config is in the current default config
location or the config location provided by the command-line argument. It can
only be renamed or moved by using the command-line argument.
- If no custom config location is set for a profile, it will be located under
"~/.config/digikam/<profileXYZ>" (or a similar location decided by the devs).
- Digikam windows will append the name of the active profile to the window name
to differentiate them.
- Digikam windows of different profiles should be differentiated in such a way
that they are not stacked together in the taskbar (but windows of the same
profile and child windows/dialogs are stacked/treated the same).
ADDITIONAL INFORMATION
Multiple configs are particularly useful when you are using a remote database
for multi-user support. If you are away from the local network you can't use
Digikam without a VPN which is so slow that Digikam becomes unusable. Starting
Digikam with a secondary config/database specifically for local collections
(using the command line argument) allows you to use Digikam locally without a
fast connection (or any connection) to the shared database. As more and more
people have access to home NAS devices to host their photos and Digikam
database, this issue only becomes more necessary to solve.
Additionally, multiple configs are useful in other situations such as allowing
you to keep your private/local collections more separated from shared family
ones, allowing multiple remote databases to be used (Ex: shared family NAS DB
and shared work DB), and allowing separate behaviors for different needs (Ex:
one config can be performance-oriented, while another can be focused on the
highest quality screen rendering and most up to date image/metadata info
syncing).
Because of all of these uses, I believe a GUI option for multiple configs is
important to have.
--
You are receiving this mail because:
You are watching all bug changes.
