.dtrash is empty and full?

[Peter Mc Donough]

Hi,

There is the trash folder in Digikam ".dtrash", which is a nice idea for
those without KDE.
Presently it is empty, but (!) if I check with dolphin, there are still
about 250MB of photos.
System Suse Tumbleweed, Digikam 5.2.0

Which settings am I missing?
Alternatively, is there somewhere an option within Digikam for using the
kde trash folder like in digkam 4.x, or could I simply link .dtash to my
kde trash folder without causing problems?

cu
Peter

[Remco Viëtor]

On lundi 31 octobre 2016 12:18:44 CET Peter Mc Donough wrote:
> Hi,
>
> There is the trash folder in Digikam ".dtrash", which is a nice idea for
> those without KDE.
> Presently it is empty, but (!) if I check with dolphin, there are still
> about 250MB of photos.
> System Suse Tumbleweed, Digikam 5.2.0
>
> Which settings am I missing?

Looking in that folder on my system, I see two folders beneath it:
- "files", containing .ARW and .XMP files
- "info", containing .dtrashinfo files, one for each file in the "files"
directory.

Could it be that in your case, the "info" directory is empty?

> Alternatively, is there somewhere an option within Digikam for using the
> kde trash folder like in digkam 4.x, or could I simply link .dtash to my
> kde trash folder without causing problems?
>

I'd expect the presence of the "info" directory and .dtrashinfo files to cause
problems if you make .dtrash a link to the KDE trash folder (either the
"dtrash" could (appear to) be corrupted after emptying the KDE trash or KDE
trash could show strange behaviour due to the ".dtrash" elements present)

[Peter Mc Donough]

Am 31.10.2016 um 14:47 schrieb Remco Viëtor:

> On lundi 31 octobre 2016 12:18:44 CET Peter Mc Donough wrote:
>>
>> There is the trash folder in Digikam ".dtrash", ...
>> Presently it is empty, but (!) if I check with dolphin, there are still
>> about 250MB of photos. System Suse Tumbleweed, Digikam 5.2.0
>> Which settings am I missing?
>
> Looking in that folder on my system, I see two folders beneath it:
> - "files", containing .ARW and .XMP files
> - "info", containing .dtrashinfo files, one for each file in the "files"
> directory.
> Could it be that in your case, the "info" directory is empty?

No, both contain the same number of files.
Meanwhile the problem sorted itself out.
I deleted another photo and suddenly the trash folder contained all
files that I could see in dolphin. Then I could delete all those within
Digikam.
>
>> Alternatively, is there somewhere an option within Digikam for using the
>> kde trash folder like in digkam 4.x, or could I simply link .dtash to my
>> kde trash folder without causing problems?
>
> I'd expect the presence of the "info" directory and .dtrashinfo files to cause
> problems if you make .dtrash a link to the KDE trash folder (either the
> "dtrash" could (appear to) be corrupted after emptying the KDE trash or KDE
> trash could show strange behaviour due to the ".dtrash" elements present)

KDE trash also has two folders: "files" and "info", so Digikam after
"ln -s ~/local/share/Trash .dtrash"
should just see what it expects, IF, and that is a big "if", it uses the
system resources and not an own trash management.

I played it bit with the link. After setting the link, deleted files
didn't show up in KDE trash.
So I better leave it alone.

cu
Peter

[Gilles Caulier-4]

There is a digiKam trash for each collection (local or removable). You cannot use KDE trash with a link.

With 5.3.0, we have fixed some problem with trash. Try beta AppImage for Linux 64 bits :

https://drive.google.com/open?id=0BzeiVr-byqt5SUZRMGtWa3VCUDg

Gilles Caulier

2016-10-31 18:42 GMT+01:00 Peter Mc Donough <[hidden email]>:

Am 31.10.2016 um 14:47 schrieb Remco Viëtor:

On lundi 31 octobre 2016 12:18:44 CET Peter Mc Donough wrote:

There is the trash folder in Digikam ".dtrash", ...
Presently it is empty, but (!) if I check with dolphin, there are still
about 250MB of photos. System Suse Tumbleweed, Digikam 5.2.0
Which settings am I missing?

Looking in that folder on my system, I see two folders beneath it:
- "files", containing .ARW and .XMP files
- "info", containing .dtrashinfo files, one for each file in the "files"
directory.
Could it be that in your case, the "info" directory is empty?

No, both contain the same number of files.
Meanwhile the problem sorted itself out.
I deleted another photo and suddenly the trash folder contained all files that I could see in dolphin. Then I could delete all those within Digikam.

Alternatively, is there somewhere an option within Digikam for using the
kde trash folder like in digkam 4.x, or could I simply link .dtash to my
kde trash folder without causing problems?

I'd expect the presence of the "info" directory and .dtrashinfo files to cause
problems if you make .dtrash a link to the KDE trash folder (either the
"dtrash" could (appear to) be corrupted after emptying the KDE trash or KDE
trash could show strange behaviour due to the ".dtrash" elements present)

KDE trash also has two folders: "files" and "info", so Digikam after
"ln -s ~/local/share/Trash .dtrash"
should just see what it expects, IF, and that is a big "if", it uses the system resources and not an own trash management.

I played it bit with the link. After setting the link, deleted files didn't show up in KDE trash.
So I better leave it alone.

cu
Peter

[Peter Mc Donough]

Am 31.10.2016 um 19:25 schrieb Gilles Caulier:
> There is a digiKam trash for each collection (local or removable). You
> cannot use KDE trash with a link.
>
> With 5.3.0, we have fixed some problem with trash. Try beta AppImage for
> Linux 64 bits :

Thank you, I'll stick with digikam.

cu
Peter

[Peter Mc Donough]

Am 31.10.2016 um 19:25 schrieb Gilles Caulier:
> There is a digiKam trash for each collection (local or removable). You
> cannot use KDE trash with a link.
>
> With 5.3.0, we have fixed some problem with trash. Try beta AppImage for
> Linux 64 bits :
> ....
>> ...
>> I deleted another photo and suddenly the trash folder contained all files
>> that I could see in dolphin. Then I could delete all those within Digikam.
...

There is obviously a refresh mechanism at work. Does Digikam also
refresh ".dtrash" at start up per default.

cu
Peter

[Boudewijn]

On Monday, October 31, 2016 10:34:03 PM CET Peter Mc Donough wrote:
> Am 31.10.2016 um 19:25 schrieb Gilles Caulier:
> > There is a digiKam trash for each collection (local or removable). You
> > cannot use KDE trash with a link.
> >
> > With 5.3.0, we have fixed some problem with trash. Try beta AppImage for
> > Linux 64 bits :

> Thank you, I'll stick with digikam.

You may not be aware that "AppImage" is not an image-management-"app", but the
specific way in which the latest and freshest DigiKam is made available in a
timely and consistent manner.

Best regards,

Boudewijn

> You may not be aware that "AppImage" is not an image-management-"app", but the
> specific way in which the latest and freshest DigiKam is made available in a
> timely and consistent manner.

Unfortunate clash of nomenclature - I hadn't recognised it until mentioned.

I wonder if this will be a constant issue into the future.

[Peter Mc Donough]

Am 01.11.2016 um 20:44 schrieb Boudewijn:

> On Monday, October 31, 2016 10:34:03 PM CET Peter Mc Donough wrote:
>> Am 31.10.2016 um 19:25 schrieb Gilles Caulier:
>>> There is a digiKam trash for each collection (local or removable). You
>>> cannot use KDE trash with a link.
>>>
>>> With 5.3.0, we have fixed some problem with trash. Try beta AppImage for
>>> Linux 64 bits :
>
>> Thank you, I'll stick with digikam.
>
> You may not be aware that "AppImage" is not an image-management-"app", but the
> specific way in which the latest and freshest DigiKam is made available in a
> timely and consistent manner.

No, I'm not.
I checked the info on AppImage. It sounds rather promising, but doesn't
it leave part of the unix philosophy behind by bringing its own libs in
one home directory, i.e. for each user one on one computer?

cu
Peter

[Gilles Caulier-4]

You are right, but...

1/ It permit to run digiKam on Linux distro where it's not packaged.

2/ It permit to use the last stable version quickly.

3/ It permit to use version on development and to test last changes from developers, few hours are a patch applied to source code

4/ It permit to non developer users to use last code without to compile anything

5/ It permit to have a bundle of all dependencies required by digiKam packaged well as it must do for the application in goal to have something stable as it must.

6/ Windows and OSX use this bundle way to deploy applications, and it's work. Why not under Linux too...

7/ ... And more...

Gilles Caulier

2016-11-04 23:10 GMT+01:00 Peter Mc Donough <[hidden email]>:

Am 01.11.2016 um 20:44 schrieb Boudewijn:

On Monday, October 31, 2016 10:34:03 PM CET Peter Mc Donough wrote:

Am 31.10.2016 um 19:25 schrieb Gilles Caulier:

There is a digiKam trash for each collection (local or removable). You
cannot use KDE trash with a link.

With 5.3.0, we have fixed some problem with trash. Try beta AppImage for
Linux 64 bits :

Thank you, I'll stick with digikam.

You may not be aware that "AppImage" is not an image-management-"app", but the
specific way in which the latest and freshest DigiKam is made available in a
timely and consistent manner.

No, I'm not.
I checked the info on AppImage. It sounds rather promising, but doesn't it leave part of the unix philosophy behind by bringing its own libs in one home directory, i.e. for each user one on one computer?

cu
Peter

[Peter Mc Donough]

Am 04.11.2016 um 23:40 schrieb Gilles Caulier:

> You are right, but...
>
> 1/ It permit to run digiKam on Linux distro where it's not packaged.
> 2/ It permit to use the last stable version quickly.
> 3/ It permit to use version on development and to test last changes from
> developers, few hours are a patch applied to source code
> 4/ It permit to non developer users to use last code without to compile
> anything
> 5/ It permit to have a bundle of all dependencies required by digiKam
> packaged well as it must do for the application in goal to have something
> stable as it must.
> 6/ Windows and OSX use this bundle way to deploy applications, and it's
> work. Why not under Linux too...
> 7/ ... And more...

All true.
I have no problem with all of digikam installed as user in an linux
environment as long as it doesn't require any libs installed as root.
In other words, no update or dependency hell like in Windows.

How does user-digikam access system provided monitor calibration?

cu
Peter

[Gilles Caulier-4]

2016-11-05 18:04 GMT+01:00 Peter Mc Donough <[hidden email]>:

Am 04.11.2016 um 23:40 schrieb Gilles Caulier:

You are right, but...

1/ It permit to run digiKam on Linux distro where it's not packaged.
2/ It permit to use the last stable version quickly.
3/ It permit to use version on development and to test last changes from
developers, few hours are a patch applied to source code
4/ It permit to non developer users to use last code without to compile
anything
5/ It permit to have a bundle of all dependencies required by digiKam
packaged well as it must do for the application in goal to have something
stable as it must.
6/ Windows and OSX use this bundle way to deploy applications, and it's
work. Why not under Linux too...
7/ ... And more...

All true.
I have no problem with all of digikam installed as user in an linux environment as long as it doesn't require any libs installed as root.
In other words, no update or dependency hell like in Windows.

How does user-digikam access system provided monitor calibration?

There is no screen calibration tool in DK.

You do it on your system with relevant tool, you generate ICC profiles, you put it on you home directory (there are standard place typically), and when you run DK, it will check these place and propose this ICC profile to use from screen.

Second possibility is to setup ICC profile in X11 server. It will be used by DK automatically.

Gilles Caulier

cu
Peter