[digiKam-users] How to start a completely new and separate digikam from appimage?

[Chris Green]

I want to run a copy of digikam completely separately from my main
picture album tree.  This is to view a temporarily created tree of
pictures.

Using the 6.4 appimage how can one do this?  I can specify a separate
database but I can't seem to make it use a separate config file.  If I
use the --config pointing at a new file it just complains that the
file doesn't exist.

--
Chris Green

[Maik Qualmann]

The "--config" parameter is the right one. Only the specified file must exist.
So either a copy of an existing "digikamrc" or a new file with 0 bytes.

Maik

Am Montag, 25. November 2019, 21:21:58 CET schrieb Chris Green:
> I want to run a copy of digikam completely separately from my main
> picture album tree.  This is to view a temporarily created tree of
> pictures.
>
> Using the 6.4 appimage how can one do this?  I can specify a separate
> database but I can't seem to make it use a separate config file.  If I
> use the --config pointing at a new file it just complains that the
> file doesn't exist.

[Chris Green]

Maik Qualmann <[hidden email]> wrote:

> Maik
>
> Am Montag, 25. November 2019, 21:21:58 CET schrieb Chris Green:
> > I want to run a copy of digikam completely separately from my main
> > picture album tree.  This is to view a temporarily created tree of
> > pictures.
> >
> > Using the 6.4 appimage how can one do this?  I can specify a separate
> > database but I can't seem to make it use a separate config file.  If I
> > use the --config pointing at a new file it just complains that the
> > file doesn't exist.
>
> The "--config" parameter is the right one. Only the specified file must exist.
> So either a copy of an existing "digikamrc" or a new file with 0 bytes.
>

Thanks, that at least explains why I couldn't get it to work! :-)

It seems a bit odd though, it makes it very difficult to start a
'clean' copy of digikam.

--
Chris Green
·

[woenx]

Alternatively, you can launch digikam from a command line with the
--database-directory <dir> parameter, so it uses a clean database in another
directory.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Chris Green]

On Mon, Nov 25, 2019 at 05:39:14PM -0600, woenx wrote:
> Alternatively, you can launch digikam from a command line with the
> --database-directory <dir> parameter, so it uses a clean database in another
> directory.
>
Surely a clean configuration file is a good idea as well.


It would be good to have this clearly outlined somewhere as it can be
quite confusing and difficult.  I.e. where are the following
confuguration items stored:-

    Database name - is this saved anywhere?  If it isn't saved
    anywhere is there a default name and location.  I know it can be
    changed by a command line parameter.

    Configuration file name and location - I know this defaults to
    ~/.config/digikamrc which is fairly standard (though it would
    really be more 'standard' to be ~/.config/digikam/digikamrc).
    What is stored in the configuration file, it doesn't seem to have
    anything about the database or album locations.

    Album directories - I've looked and seen that these are stored in
    the database but it would be helpful is this was explained
    somewhere (maybe it is but it should be really 'up front' for me).

What determines whether configuration information is stored in the
configuration file or in the database, is there any rationale for
where things are stored?

--
Chris Green

Le 26/11/2019 à 01:00, Chris Green a écrit :

> It would be good to have this clearly outlined somewhere

in a terminal (just open, so in ~), digikam -h gives clues.

dogikam --config new gives an error message

touch new

and digikam starts with it's config dialog


jdd
--
http://dodin.org

[Remco Viëtor]

On mardi 26 novembre 2019 01:00:27 CET Chris Green wrote:

> On Mon, Nov 25, 2019 at 05:39:14PM -0600, woenx wrote:
> > Alternatively, you can launch digikam from a command line with the
> > --database-directory <dir> parameter, so it uses a clean database in
> > another directory.
>
> Surely a clean configuration file is a good idea as well.
>
>
> It would be good to have this clearly outlined somewhere as it can be
> quite confusing and difficult.

Of course having everything clearly outlined would be good. But that would
mean a significant number of extra pages to wade through to find what you
want, or having a *good* index (which requires a tremendous amount of work to
create and maintain, just a generated list of terms with page references is
not enough).

> I.e. where are the following
> confuguration items stored:-
>
>     Database name - is this saved anywhere?  If it isn't saved
>     anywhere is there a default name and location.  I know it can be
>     changed by a command line parameter.

Database file *names* are (perhaps) not stored in digikamrc, but there is a
line in mine
"Database File Path=<xxxxx>", and also a line
"Album Path=<xxxx>".
As DK uses 3 or 4 databases, having standard names is perhaps not such a bad
idea...

>     Configuration file name and location - I know this defaults to
>     ~/.config/digikamrc which is fairly standard (though it would
>     really be more 'standard' to be ~/.config/digikam/digikamrc).

Those *have* to have a default, or the program cannot start without a correct
command line parameter, more complicated than necessary for normal use.
The name and location look pretty standard for a KDE program, which Digikam
is, or at least was originally (and creating a config directory for one or two
config files seems overkill, IMO).

>     What is stored in the configuration file, it doesn't seem to have
>     anything about the database or album locations.
>     Album directories - I've looked and seen that these are stored in
>     the database but it would be helpful is this was explained
>     somewhere (maybe it is but it should be really 'up front' for me).

See above...

> What determines whether configuration information is stored in the
> configuration file or in the database, is there any rationale for
> where things are stored?

[Chris Green]

woenx <[hidden email]> wrote:
> Alternatively, you can launch digikam from a command line with the
> --database-directory <dir> parameter, so it uses a clean database in another
> directory.
>
Yes, but there needs to be a clear explanation somewhere that comes to
hand quickly/easily that a clean database will effectively produce a
clean new install.  One usually expects that a new configuration file
will produce a clean installation but with digikam this isn't so.

My expectation (which is the way things are with many programs) is
that the location of the database and of the albums would be set in
the configuration file.  If this isn't so (as it isn't with digikam)
this should be made clear at the beginning of the documentation.

It does seem to me that there are a lot of questions/problems relating
to this issue.

--
Chris Green
·

[Chris Green]

> On mardi 26 novembre 2019 01:00:27 CET Chris Green wrote:
> > On Mon, Nov 25, 2019 at 05:39:14PM -0600, woenx wrote:
> > > Alternatively, you can launch digikam from a command line with the
> > > --database-directory <dir> parameter, so it uses a clean database in
> > > another directory.
> >
> > Surely a clean configuration file is a good idea as well.
> >
> >
> > It would be good to have this clearly outlined somewhere as it can be
> > quite confusing and difficult.
>
> Of course having everything clearly outlined would be good. But that would
> mean a significant number of extra pages to wade through to find what you
> want, or having a *good* index (which requires a tremendous amount of work to
> create and maintain, just a generated list of terms with page references is
> not enough).
>

Yes, I realise it's not easy, but even quite a short paragraph
somewhere 'obvious' (as in seen by new users/installers) seems to me
to be a good idea.  

> > I.e. where are the following
> > confuguration items stored:-
> >
> >     Database name - is this saved anywhere?  If it isn't saved
> >     anywhere is there a default name and location.  I know it can be
> >     changed by a command line parameter.
>
> Database file *names* are (perhaps) not stored in digikamrc, but there is a
> line in mine
> "Database File Path=<xxxxx>", and also a line
> "Album Path=<xxxx>".
> As DK uses 3 or 4 databases, having standard names is perhaps not such a bad
> idea...

There's neither of those in my ~/.config/digikamrc, if I search for
'Path' (ignoring case) I see:-
    DefaultPath=
    tagPaths=1
    Internal Database Server Path=
    OutputPath=file:///home/chris/doc

... and if I search for 'database' I see:-
    [Database Settings]
    Database Connectoptions=
    Database Hostname=
    Database Name=/chris/digikam/
    Database Name Face=/chris/digikam/
    Database Name Similarity=/chris/digikam/
    Database Name Thumbnails=/chris/digikam/
    Database Password=
    Database Port=-1
    Database Type=QSQLITE
    Database Username=
    Internal Database Server=false
    Internal Database Server Mysql Init Command=
    Internal Database Server Mysql Server Command=
    Internal Database Server Path=
    CleanupDatabase=false
    CleanupFacesDatabase=false
    CleanupThumbDatabase=false
    ShrinkDatabases=false

(I have an odd setup with the digikam databases stored in /chris/digikam/
because that is a faster, separately mounted disk drive)

So, yes, the database[s] location is stored in the config file, but
there doesn't seem to be any album path set.

>
> >     Configuration file name and location - I know this defaults to
> >     ~/.config/digikamrc which is fairly standard (though it would
> >     really be more 'standard' to be ~/.config/digikam/digikamrc).
>
> Those *have* to have a default, or the program cannot start without a correct
> command line parameter, more complicated than necessary for normal use.
> The name and location look pretty standard for a KDE program, which Digikam
> is, or at least was originally (and creating a config directory for one or two
> config files seems overkill, IMO).
>

Yes, they do need a default and as I said it is "fairly standard",
I've no real problem with this. :-)

--
Chris Green

[Remco Viëtor]

On mardi 26 novembre 2019 10:33:07 CET Chris Green wrote:
> woenx <[hidden email]> wrote:
> > Alternatively, you can launch digikam from a command line with the
> > --database-directory <dir> parameter, so it uses a clean database in
> > another directory.
>
> Yes, but there needs to be a clear explanation somewhere that comes to
> hand quickly/easily that a clean database will effectively produce a
> clean new install.  One usually expects that a new configuration file
> will produce a clean installation but with digikam this isn't so.

That depends on what you call a "clean new installation".

I may hope that removing the digikamrc file will *not* touch the data (of
which the database is a part).

Otoh, I'd rather not see creating a new database remove all the careful
configuration of defaults I did in the program (e.g. displayed metadata,
sidecar use and data, ...)

> My expectation (which is the way things are with many programs) is
> that the location of the database and of the albums would be set in
> the configuration file.  If this isn't so (as it isn't with digikam)
> this should be made clear at the beginning of the documentation.

Did you notice the "Album Path=" and "Database File Path=" entries in
digikamrc ([Album Settings] section)? Looks like those give the location of
the databases (not the names!) and of the album roots (they do on my
system...).
So those two items *are* set in the configuration file, as you expect (and
have been defined by the user through the digikam GUI, btw).

> It does seem to me that there are a lot of questions/problems relating
> to this issue.
No comment...

[Chris Green]

On Tue, Nov 26, 2019 at 11:26:58AM +0100, Remco Viëtor wrote:
> On mardi 26 novembre 2019 10:33:07 CET Chris Green wrote:
> > woenx <[hidden email]> wrote:
>
> Otoh, I'd rather not see creating a new database remove all the careful
> configuration of defaults I did in the program (e.g. displayed metadata,
> sidecar use and data, ...)
>
Well, personally, I wisj the database would go away altogether! :-)

I want *all* my settings stored with the image files so that I know
that when I back them up I have saved everytyhing important.  Yes, OK,
I know others don't want to work that way but I don't think I'm in a
minority of one!  :-)


> > My expectation (which is the way things are with many programs) is
> > that the location of the database and of the albums would be set in
> > the configuration file.  If this isn't so (as it isn't with digikam)
> > this should be made clear at the beginning of the documentation.
>
> Did you notice the "Album Path=" and "Database File Path=" entries in
> digikamrc ([Album Settings] section)? Looks like those give the location of
> the databases (not the names!) and of the album roots (they do on my
> system...).

The database path is there but there's no sign of album path in my
config file.  I'm pretty certain the album paths are stored in the
database so if they were/are in the config file as well then it will
cause problems won't it?

--
Chris Green

[Remco Viëtor]

On mardi 26 novembre 2019 13:06:32 CET Chris Green wrote:

> On Tue, Nov 26, 2019 at 11:26:58AM +0100, Remco Viëtor wrote:
> > On mardi 26 novembre 2019 10:33:07 CET Chris Green wrote:
> > > woenx <[hidden email]> wrote:
> > Otoh, I'd rather not see creating a new database remove all the careful
> > configuration of defaults I did in the program (e.g. displayed metadata,
> > sidecar use and data, ...)
>
> Well, personally, I wisj the database would go away altogether! :-)
>
> I want *all* my settings stored with the image files so that I know
> that when I back them up I have saved everytyhing important.  Yes, OK,
> I know others don't want to work that way but I don't think I'm in a
> minority of one!  :-)

That's why there are sidecar files.

It would probably be possible to do searches (e.g. on keyword) without a
database. It would just imply a reading of all the images (or sidecars) in the
selected albums; doable for a few hundred images on a local disk, but some
here have collections that contain tens of thousands of images on network
disks.

> > > My expectation (which is the way things are with many programs) is
> > > that the location of the database and of the albums would be set in
> > > the configuration file.  If this isn't so (as it isn't with digikam)
> > > this should be made clear at the beginning of the documentation.
> >
> > Did you notice the "Album Path=" and "Database File Path=" entries in
> > digikamrc ([Album Settings] section)? Looks like those give the location
> > of
> > the databases (not the names!) and of the album roots (they do on my
> > system...).
>
> The database path is there but there's no sign of album path in my
> config file.  I'm pretty certain the album paths are stored in the
> database so if they were/are in the config file as well then it will
> cause problems won't it?

The "Album Path" points to the root of my collection, so yeah, the database
would need to store the rest of the path to a given album. No reason why that
would cause problems (full path is config root + db path).

But going back to your original problem, if you need to work on a separate and
temporay collection, and you don't want to pollute your permanent database,
one option could be to create a separate user for work on that tree, and use
Digikam from there (and possibly other programs). Fresh database and config,
and not all that hard to switch users on a modern Linux (though you wouldn't
want to do it every 5 minutes, either).

And, if all you want to do is *view* a separate tree (as you stated), perhaps
Digikam isn't the best program to use (Gwenview comes to mind as an easily
available option if you use KDE, and allows you to show metadata).

[Chris Green]

On Tue, Nov 26, 2019 at 02:51:42PM +0100, Remco Viëtor wrote:

> On mardi 26 novembre 2019 13:06:32 CET Chris Green wrote:
> > On Tue, Nov 26, 2019 at 11:26:58AM +0100, Remco Viëtor wrote:
> > > On mardi 26 novembre 2019 10:33:07 CET Chris Green wrote:
> > I want *all* my settings stored with the image files so that I know
> > that when I back them up I have saved everytyhing important.  Yes, OK,
> > I know others don't want to work that way but I don't think I'm in a
> > minority of one!  :-)
>
> That's why there are sidecar files.
>
> It would probably be possible to do searches (e.g. on keyword) without a
> database. It would just imply a reading of all the images (or sidecars) in the
> selected albums; doable for a few hundred images on a local disk, but some
> here have collections that contain tens of thousands of images on network
> disks.
>

I have over 30000 images.

> > > > My expectation (which is the way things are with many programs) is
> > > > that the location of the database and of the albums would be set in
> > > > the configuration file.  If this isn't so (as it isn't with digikam)
> > > > this should be made clear at the beginning of the documentation.
> > >
> > > Did you notice the "Album Path=" and "Database File Path=" entries in
> > > digikamrc ([Album Settings] section)? Looks like those give the location
> > > of
> > > the databases (not the names!) and of the album roots (they do on my
> > > system...).
> >
> > The database path is there but there's no sign of album path in my
> > config file.  I'm pretty certain the album paths are stored in the
> > database so if they were/are in the config file as well then it will
> > cause problems won't it?
>
> The "Album Path" points to the root of my collection, so yeah, the database
> would need to store the rest of the path to a given album. No reason why that
> would cause problems (full path is config root + db path).
>

There is simply no "Album Path" in my config file.

> But going back to your original problem, if you need to work on a separate and
> temporay collection, and you don't want to pollute your permanent database,
> one option could be to create a separate user for work on that tree, and use
> Digikam from there (and possibly other programs). Fresh database and config,
> and not all that hard to switch users on a modern Linux (though you wouldn't
> want to do it every 5 minutes, either).
>
Yes, I did consider doing that actually but it feels 'wrong' somehow.
It also means I can't see both at the same time on the same desktop
which is sometimes useful.


> And, if all you want to do is *view* a separate tree (as you stated), perhaps
> Digikam isn't the best program to use (Gwenview comes to mind as an easily
> available option if you use KDE, and allows you to show metadata).
>
No, I want to tag things in a useful (and consistent) way, digikam is
good at this.

--
Chris Green

[Simon Frei]

On 26/11/2019 15:55, Chris Green wrote:

> On Tue, Nov 26, 2019 at 02:51:42PM +0100, Remco Viëtor wrote:
>> On mardi 26 novembre 2019 13:06:32 CET Chris Green wrote:
>> But going back to your original problem, if you need to work on a separate and
>> temporay collection, and you don't want to pollute your permanent database,
>> one option could be to create a separate user for work on that tree, and use
>> Digikam from there (and possibly other programs). Fresh database and config,
>> and not all that hard to switch users on a modern Linux (though you wouldn't
>> want to do it every 5 minutes, either).
>>
> Yes, I did consider doing that actually but it feels 'wrong' somehow.
> It also means I can't see both at the same time on the same desktop
> which is sometimes useful.
>
>
>> And, if all you want to do is *view* a separate tree (as you stated), perhaps
>> Digikam isn't the best program to use (Gwenview comes to mind as an easily
>> available option if you use KDE, and allows you to show metadata).
>>
> No, I want to tag things in a useful (and consistent) way, digikam is
> good at this.
>

digiKam comes also in a no-db variant: showFoto. For working on
something temporary you can just use that. If you then import the
temporary tree into the "regular digiKam", tags written to xmp/files
will be picked up.

[Chris Green]

On Tue, Nov 26, 2019 at 04:12:17PM +0100, Simon Frei wrote:

> On 26/11/2019 15:55, Chris Green wrote:
> > On Tue, Nov 26, 2019 at 02:51:42PM +0100, Remco Viëtor wrote:
> >> On mardi 26 novembre 2019 13:06:32 CET Chris Green wrote:
> >> But going back to your original problem, if you need to work on a separate and
> >> temporay collection, and you don't want to pollute your permanent database,
> >> one option could be to create a separate user for work on that tree, and use
> >> Digikam from there (and possibly other programs). Fresh database and config,
> >> and not all that hard to switch users on a modern Linux (though you wouldn't
> >> want to do it every 5 minutes, either).
> >>
> > Yes, I did consider doing that actually but it feels 'wrong' somehow.
> > It also means I can't see both at the same time on the same desktop
> > which is sometimes useful.
> >
> >
> >> And, if all you want to do is *view* a separate tree (as you stated), perhaps
> >> Digikam isn't the best program to use (Gwenview comes to mind as an easily
> >> available option if you use KDE, and allows you to show metadata).
> >>
> > No, I want to tag things in a useful (and consistent) way, digikam is
> > good at this.
> >
> digiKam comes also in a no-db variant: showFoto. For working on
> something temporary you can just use that. If you then import the
> temporary tree into the "regular digiKam", tags written to xmp/files
> will be picked up.

Ah!  Now that really might be very useful, thank you.  I'd never
realised that this is what showFoto is.

--
Chris Green

[Maik Qualmann]

An explanation of the paths. The path to the database is stored in the
configuration file or the corresponding database options (network address,
port, user, etc.) for a MySQL database. There is currently no album path that
is used, if you find such an option, it comes from a very very old
configuration. The album root path is stored in the database for each
collection. In current digiKam versions, it is very easy to adjust the
albumroot path in the collection setup if the collection has been moved to a
different drive or similar.

Maik

Am Dienstag, 26. November 2019, 16:46:44 CET schrieb Chris Green:

> On Tue, Nov 26, 2019 at 04:12:17PM +0100, Simon Frei wrote:
> > On 26/11/2019 15:55, Chris Green wrote:
> > > On Tue, Nov 26, 2019 at 02:51:42PM +0100, Remco Viëtor wrote:
> > >> On mardi 26 novembre 2019 13:06:32 CET Chris Green wrote:
> > >> But going back to your original problem, if you need to work on a
> > >> separate and temporay collection, and you don't want to pollute your
> > >> permanent database, one option could be to create a separate user for
> > >> work on that tree, and use Digikam from there (and possibly other
> > >> programs). Fresh database and config, and not all that hard to switch
> > >> users on a modern Linux (though you wouldn't want to do it every 5
> > >> minutes, either).
> > >
> > > Yes, I did consider doing that actually but it feels 'wrong' somehow.
> > > It also means I can't see both at the same time on the same desktop
> > > which is sometimes useful.
> > >
> > >> And, if all you want to do is *view* a separate tree (as you stated),
> > >> perhaps Digikam isn't the best program to use (Gwenview comes to mind
> > >> as an easily available option if you use KDE, and allows you to show
> > >> metadata).> >
> > > No, I want to tag things in a useful (and consistent) way, digikam is
> > > good at this.
> >
> > digiKam comes also in a no-db variant: showFoto. For working on
> > something temporary you can just use that. If you then import the
> > temporary tree into the "regular digiKam", tags written to xmp/files
> > will be picked up.
>
> Ah!  Now that really might be very useful, thank you.  I'd never
> realised that this is what showFoto is.

[Remco Viëtor]

On mardi 26 novembre 2019 18:32:19 CET Maik Qualmann wrote:
> An explanation of the paths. The path to the database is stored in the
> configuration file or the corresponding database options (network address,
> port, user, etc.) for a MySQL database. There is currently no album path
> that is used, if you find such an option, it comes from a very very old
> configuration. The album root path is stored in the database for each
> collection. In current digiKam versions, it is very easy to adjust the
> albumroot path in the collection setup if the collection has been moved to
> a different drive or similar.

It's quite possible that the "Album path" option is a relic of very old
versions, as I have been using DK for about 10 years now.
So that could explain that discrepancy.

Remco

[Chris Green]

On Tue, Nov 26, 2019 at 06:32:19PM +0100, Maik Qualmann wrote:
> An explanation of the paths. The path to the database is stored in the
> configuration file or the corresponding database options (network address,
> port, user, etc.) for a MySQL database. There is currently no album path that
> is used, if you find such an option, it comes from a very very old
> configuration. The album root path is stored in the database for each
> collection. In current digiKam versions, it is very easy to adjust the
> albumroot path in the collection setup if the collection has been moved to a
> different drive or similar.
>
Yes, the only extra issue with moving to a different drive is that if
the original drive is still around digikam will find that one as well
using its UUID.

I had two albums with the same name as a result of this! :-)

It would be handy if one could tell digikam that a collection has been
cloned to another drive such that the only information that changes is
the drive ID and the database keeps the picture data as that won't
have changed.

--
Chris Green

[Maik Qualmann]

And exactly this point is easily possible. Go to the collection setup, click
on the update button in the old collections and select the new directory. All
metadata is preserved, drive UUID and path are updated. Of course, the album
substructure must be identical.

Maik

Am Dienstag, 26. November 2019, 19:52:31 CET schrieb Chris Green:

> On Tue, Nov 26, 2019 at 06:32:19PM +0100, Maik Qualmann wrote:
> > An explanation of the paths. The path to the database is stored in the
> > configuration file or the corresponding database options (network address,
> > port, user, etc.) for a MySQL database. There is currently no album path
> > that is used, if you find such an option, it comes from a very very old
> > configuration. The album root path is stored in the database for each
> > collection. In current digiKam versions, it is very easy to adjust the
> > albumroot path in the collection setup if the collection has been moved
> > to a different drive or similar.
>
> Yes, the only extra issue with moving to a different drive is that if
> the original drive is still around digikam will find that one as well
> using its UUID.
>
> I had two albums with the same name as a result of this! :-)
>
> It would be handy if one could tell digikam that a collection has been
> cloned to another drive such that the only information that changes is
> the drive ID and the database keeps the picture data as that won't
> have changed.

[Chris Green]

On Tue, Nov 26, 2019 at 08:04:23PM +0100, Maik Qualmann wrote:
> And exactly this point is easily possible. Go to the collection setup, click
> on the update button in the old collections and select the new directory. All
> metadata is preserved, drive UUID and path are updated. Of course, the album
> substructure must be identical.
>
I can't see an 'update' button, unless you mean that one with pointers
round in a circle, and that doesn't seem to do what you're saying.  I
may of course be wrong but it's far from obvious.

When I go to Collections I see a list of three sorts of collections,
on the one I'm seeing at the moment only the Local Collections one has
an entry, called 'pictures'.

Against 'pictures' there are two buttons to click, one is the rotating
arrows I refer to above and the other is a dustbin for deleting it
(presumably).  If I click the two rotating arrows I get a box saying
"Your collection will use this this category", are you saying this
will actually *copy* my collection?  It would appear so but I have to
say it's far from obvious.


--
Chris Green