[digiKam-users] Digikam not showing non-image files in album view

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[digiKam-users] Digikam not showing non-image files in album view

Thomas D
Hi,

Digikam does not show any non-image files in album view nor does it seem there is an option to have it show non-image files. This is quite annoying since often mobile phone images contain the image file plus a side-car file like img_2655.aae or maybe there are just some other files in the folder. This can lead to unexpected data loss when the user deletes an album that looks to be empty when viewed in Digikam but was in reality not empty.
I think there should at least be (an easy) way of toggling whether non-image files are shown or not. They can just be shown with a completely generic file icon as thumbnail. 

I tested this on DK 7.

BR
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Maik Qualmann
That is the intention. What you see in the thumbnail view comes from the
database, which is created by a scan. You can open an album with a file
manager to see the actual content. You can also add unknown mime types, as an
image, video or audio file and then display them as a generic icon. But
digiKam will not be able to display a preview or the like.

Maik

Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:

> Hi,
>
> Digikam does not show any non-image files in album view nor does it seem
> there is an option to have it show non-image files. This is quite annoying
> since often mobile phone images contain the image file plus a side-car file
> like img_2655.aae or maybe there are just some other files in the folder.
> This can lead to unexpected data loss when the user deletes an album that
> looks to be empty when viewed in Digikam but was in reality not empty. I
> think there should at least be (an easy) way of toggling whether non-image
> files are shown or not. They can just be shown with a completely generic
> file icon as thumbnail.
>
> I tested this on DK 7.




Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Thomas D
If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
1. Move the mouse to a tiny icon
2. Right click
3. Locate the "open in file manager" action on the list of possible actions in the right click menu
4. Click the Open in file manager action.






Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
That is the intention. What you see in the thumbnail view comes from the
database, which is created by a scan. You can open an album with a file
manager to see the actual content. You can also add unknown mime types, as an
image, video or audio file and then display them as a generic icon. But
digiKam will not be able to display a preview or the like.

Maik

Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
> Hi,
>
> Digikam does not show any non-image files in album view nor does it seem
> there is an option to have it show non-image files. This is quite annoying
> since often mobile phone images contain the image file plus a side-car file
> like img_2655.aae or maybe there are just some other files in the folder.
> This can lead to unexpected data loss when the user deletes an album that
> looks to be empty when viewed in Digikam but was in reality not empty. I
> think there should at least be (an easy) way of toggling whether non-image
> files are shown or not. They can just be shown with a completely generic
> file icon as thumbnail.
>
> I tested this on DK 7.




Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Gilles Caulier-4
This can be customized by end users :

Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.

Best

Gilles Caulier



Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :

>
> If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
> Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
> 1. Move the mouse to a tiny icon
> 2. Right click
> 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
> 4. Click the Open in file manager action.
>
>
>
>
>
>
> Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>>
>> That is the intention. What you see in the thumbnail view comes from the
>> database, which is created by a scan. You can open an album with a file
>> manager to see the actual content. You can also add unknown mime types, as an
>> image, video or audio file and then display them as a generic icon. But
>> digiKam will not be able to display a preview or the like.
>>
>> Maik
>>
>> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> > Hi,
>> >
>> > Digikam does not show any non-image files in album view nor does it seem
>> > there is an option to have it show non-image files. This is quite annoying
>> > since often mobile phone images contain the image file plus a side-car file
>> > like img_2655.aae or maybe there are just some other files in the folder.
>> > This can lead to unexpected data loss when the user deletes an album that
>> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> > think there should at least be (an easy) way of toggling whether non-image
>> > files are shown or not. They can just be shown with a completely generic
>> > file icon as thumbnail.
>> >
>> > I tested this on DK 7.
>>
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Thomas D
OK. I guess this will help. However, when trying to assign a short cut key, I am faced with this UX problem:
I try to find a key combo to open file manager.
I have now tried a handful different combos, but everyone seems to be already assigned. So I am seeing this warning:
image.png

The warning says that the chosen shortcut conflicts with the following combination: and then there is nothing after the colon.
I should be able to see what other shortcut I am about to overwrite.

Also, the text on the buttons seem rather ambiguous. "Reassign" I would think means: "OK, I see that my chosen shortcut was already used, so I will reassign that". But this is not what it means. Instead it seems to really mean "Overwrite the existing shortcut with your new shortcut."
But if I do this, then I break some unknown existing shortcut (without intention of doing that) and leaves me no way of knowing what  shortcut just got overwritten.

Also, the dialog offers no help in finding a vacant shortcut combo. For example, if I say Ctrl+E and that is taken, the program could easily try some "neighbouring" shortcuts like Ctrl+Alt+E, Ctrl+Shift+E, Alt+Shift+E, etc. and suggest some of these instead.




Den tir. 30. jun. 2020 kl. 01.59 skrev Gilles Caulier <[hidden email]>:
This can be customized by end users :

Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.

Best

Gilles Caulier



Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :
>
> If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
> Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
> 1. Move the mouse to a tiny icon
> 2. Right click
> 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
> 4. Click the Open in file manager action.
>
>
>
>
>
>
> Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>>
>> That is the intention. What you see in the thumbnail view comes from the
>> database, which is created by a scan. You can open an album with a file
>> manager to see the actual content. You can also add unknown mime types, as an
>> image, video or audio file and then display them as a generic icon. But
>> digiKam will not be able to display a preview or the like.
>>
>> Maik
>>
>> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> > Hi,
>> >
>> > Digikam does not show any non-image files in album view nor does it seem
>> > there is an option to have it show non-image files. This is quite annoying
>> > since often mobile phone images contain the image file plus a side-car file
>> > like img_2655.aae or maybe there are just some other files in the folder.
>> > This can lead to unexpected data loss when the user deletes an album that
>> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> > think there should at least be (an easy) way of toggling whether non-image
>> > files are shown or not. They can just be shown with a completely generic
>> > file icon as thumbnail.
>> >
>> > I tested this on DK 7.
>>
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Gilles Caulier-4
Thomas,

Well, this shortcuts dialog do not come from digiKam code, but from
KDE Plasma API which checks with all desktop active shortcuts. We
don't maintain this code. For all feedbacks, this must be done through
KDE bugzilla in KF5 KXMLGUI framework

Best

Gilles Caulier

Le mar. 30 juin 2020 à 03:40, Thomas D <[hidden email]> a écrit :

>
> OK. I guess this will help. However, when trying to assign a short cut key, I am faced with this UX problem:
> I try to find a key combo to open file manager.
> I have now tried a handful different combos, but everyone seems to be already assigned. So I am seeing this warning:
>
>
> The warning says that the chosen shortcut conflicts with the following combination: and then there is nothing after the colon.
> I should be able to see what other shortcut I am about to overwrite.
>
> Also, the text on the buttons seem rather ambiguous. "Reassign" I would think means: "OK, I see that my chosen shortcut was already used, so I will reassign that". But this is not what it means. Instead it seems to really mean "Overwrite the existing shortcut with your new shortcut."
> But if I do this, then I break some unknown existing shortcut (without intention of doing that) and leaves me no way of knowing what  shortcut just got overwritten.
>
> Also, the dialog offers no help in finding a vacant shortcut combo. For example, if I say Ctrl+E and that is taken, the program could easily try some "neighbouring" shortcuts like Ctrl+Alt+E, Ctrl+Shift+E, Alt+Shift+E, etc. and suggest some of these instead.
>
>
>
>
> Den tir. 30. jun. 2020 kl. 01.59 skrev Gilles Caulier <[hidden email]>:
>>
>> This can be customized by end users :
>>
>> Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.
>>
>> Best
>>
>> Gilles Caulier
>>
>>
>>
>> Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :
>> >
>> > If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
>> > Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
>> > 1. Move the mouse to a tiny icon
>> > 2. Right click
>> > 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
>> > 4. Click the Open in file manager action.
>> >
>> >
>> >
>> >
>> >
>> >
>> > Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>> >>
>> >> That is the intention. What you see in the thumbnail view comes from the
>> >> database, which is created by a scan. You can open an album with a file
>> >> manager to see the actual content. You can also add unknown mime types, as an
>> >> image, video or audio file and then display them as a generic icon. But
>> >> digiKam will not be able to display a preview or the like.
>> >>
>> >> Maik
>> >>
>> >> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> >> > Hi,
>> >> >
>> >> > Digikam does not show any non-image files in album view nor does it seem
>> >> > there is an option to have it show non-image files. This is quite annoying
>> >> > since often mobile phone images contain the image file plus a side-car file
>> >> > like img_2655.aae or maybe there are just some other files in the folder.
>> >> > This can lead to unexpected data loss when the user deletes an album that
>> >> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> >> > think there should at least be (an easy) way of toggling whether non-image
>> >> > files are shown or not. They can just be shown with a completely generic
>> >> > file icon as thumbnail.
>> >> >
>> >> > I tested this on DK 7.
>> >>
>> >>
>> >>
>> >>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Thomas D
OK. Could this be the reason why nothing is shown about the conflict? I mean, that there isnt really an actual conflict for Ctrl+E in digikam, but the conflict is in a default shortcut to some other KDE application? Problem is, this is Windows - not KDE - so I do not have any other KDE apps. So maybe this is a false positive?

Just trying to clear up what to report if this is to be reported to KDE bugzilla.


Den tir. 30. jun. 2020 kl. 10.08 skrev Gilles Caulier <[hidden email]>:
Thomas,

Well, this shortcuts dialog do not come from digiKam code, but from
KDE Plasma API which checks with all desktop active shortcuts. We
don't maintain this code. For all feedbacks, this must be done through
KDE bugzilla in KF5 KXMLGUI framework

Best

Gilles Caulier

Le mar. 30 juin 2020 à 03:40, Thomas D <[hidden email]> a écrit :
>
> OK. I guess this will help. However, when trying to assign a short cut key, I am faced with this UX problem:
> I try to find a key combo to open file manager.
> I have now tried a handful different combos, but everyone seems to be already assigned. So I am seeing this warning:
>
>
> The warning says that the chosen shortcut conflicts with the following combination: and then there is nothing after the colon.
> I should be able to see what other shortcut I am about to overwrite.
>
> Also, the text on the buttons seem rather ambiguous. "Reassign" I would think means: "OK, I see that my chosen shortcut was already used, so I will reassign that". But this is not what it means. Instead it seems to really mean "Overwrite the existing shortcut with your new shortcut."
> But if I do this, then I break some unknown existing shortcut (without intention of doing that) and leaves me no way of knowing what  shortcut just got overwritten.
>
> Also, the dialog offers no help in finding a vacant shortcut combo. For example, if I say Ctrl+E and that is taken, the program could easily try some "neighbouring" shortcuts like Ctrl+Alt+E, Ctrl+Shift+E, Alt+Shift+E, etc. and suggest some of these instead.
>
>
>
>
> Den tir. 30. jun. 2020 kl. 01.59 skrev Gilles Caulier <[hidden email]>:
>>
>> This can be customized by end users :
>>
>> Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.
>>
>> Best
>>
>> Gilles Caulier
>>
>>
>>
>> Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :
>> >
>> > If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
>> > Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
>> > 1. Move the mouse to a tiny icon
>> > 2. Right click
>> > 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
>> > 4. Click the Open in file manager action.
>> >
>> >
>> >
>> >
>> >
>> >
>> > Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>> >>
>> >> That is the intention. What you see in the thumbnail view comes from the
>> >> database, which is created by a scan. You can open an album with a file
>> >> manager to see the actual content. You can also add unknown mime types, as an
>> >> image, video or audio file and then display them as a generic icon. But
>> >> digiKam will not be able to display a preview or the like.
>> >>
>> >> Maik
>> >>
>> >> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> >> > Hi,
>> >> >
>> >> > Digikam does not show any non-image files in album view nor does it seem
>> >> > there is an option to have it show non-image files. This is quite annoying
>> >> > since often mobile phone images contain the image file plus a side-car file
>> >> > like img_2655.aae or maybe there are just some other files in the folder.
>> >> > This can lead to unexpected data loss when the user deletes an album that
>> >> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> >> > think there should at least be (an easy) way of toggling whether non-image
>> >> > files are shown or not. They can just be shown with a completely generic
>> >> > file icon as thumbnail.
>> >> >
>> >> > I tested this on DK 7.
>> >>
>> >>
>> >>
>> >>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Maik Qualmann
The problem is known, we have a bug report about it. This component comes from a KF5 / KDE library and does not work under Windows at this point. Find a unused keyboard shortcut, you can sort the list by keyboard shortcut and then click reassign.

Maik

Am Di., 30. Juni 2020 um 11:51 Uhr schrieb Thomas D <[hidden email]>:
OK. Could this be the reason why nothing is shown about the conflict? I mean, that there isnt really an actual conflict for Ctrl+E in digikam, but the conflict is in a default shortcut to some other KDE application? Problem is, this is Windows - not KDE - so I do not have any other KDE apps. So maybe this is a false positive?

Just trying to clear up what to report if this is to be reported to KDE bugzilla.


Den tir. 30. jun. 2020 kl. 10.08 skrev Gilles Caulier <[hidden email]>:
Thomas,

Well, this shortcuts dialog do not come from digiKam code, but from
KDE Plasma API which checks with all desktop active shortcuts. We
don't maintain this code. For all feedbacks, this must be done through
KDE bugzilla in KF5 KXMLGUI framework

Best

Gilles Caulier

Le mar. 30 juin 2020 à 03:40, Thomas D <[hidden email]> a écrit :
>
> OK. I guess this will help. However, when trying to assign a short cut key, I am faced with this UX problem:
> I try to find a key combo to open file manager.
> I have now tried a handful different combos, but everyone seems to be already assigned. So I am seeing this warning:
>
>
> The warning says that the chosen shortcut conflicts with the following combination: and then there is nothing after the colon.
> I should be able to see what other shortcut I am about to overwrite.
>
> Also, the text on the buttons seem rather ambiguous. "Reassign" I would think means: "OK, I see that my chosen shortcut was already used, so I will reassign that". But this is not what it means. Instead it seems to really mean "Overwrite the existing shortcut with your new shortcut."
> But if I do this, then I break some unknown existing shortcut (without intention of doing that) and leaves me no way of knowing what  shortcut just got overwritten.
>
> Also, the dialog offers no help in finding a vacant shortcut combo. For example, if I say Ctrl+E and that is taken, the program could easily try some "neighbouring" shortcuts like Ctrl+Alt+E, Ctrl+Shift+E, Alt+Shift+E, etc. and suggest some of these instead.
>
>
>
>
> Den tir. 30. jun. 2020 kl. 01.59 skrev Gilles Caulier <[hidden email]>:
>>
>> This can be customized by end users :
>>
>> Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.
>>
>> Best
>>
>> Gilles Caulier
>>
>>
>>
>> Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :
>> >
>> > If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
>> > Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
>> > 1. Move the mouse to a tiny icon
>> > 2. Right click
>> > 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
>> > 4. Click the Open in file manager action.
>> >
>> >
>> >
>> >
>> >
>> >
>> > Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>> >>
>> >> That is the intention. What you see in the thumbnail view comes from the
>> >> database, which is created by a scan. You can open an album with a file
>> >> manager to see the actual content. You can also add unknown mime types, as an
>> >> image, video or audio file and then display them as a generic icon. But
>> >> digiKam will not be able to display a preview or the like.
>> >>
>> >> Maik
>> >>
>> >> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> >> > Hi,
>> >> >
>> >> > Digikam does not show any non-image files in album view nor does it seem
>> >> > there is an option to have it show non-image files. This is quite annoying
>> >> > since often mobile phone images contain the image file plus a side-car file
>> >> > like img_2655.aae or maybe there are just some other files in the folder.
>> >> > This can lead to unexpected data loss when the user deletes an album that
>> >> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> >> > think there should at least be (an easy) way of toggling whether non-image
>> >> > files are shown or not. They can just be shown with a completely generic
>> >> > file icon as thumbnail.
>> >> >
>> >> > I tested this on DK 7.
>> >>
>> >>
>> >>
>> >>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Thomas D
OK.  Thanks for the tip.
Since this is a known problem, would it make sense to include a little note/hint in the UI about this if OS is detected as Windows?

I have included a mock-up showing how this could be presented in the dialog:

image.png




Den tir. 30. jun. 2020 kl. 13.20 skrev Maik Qualmann <[hidden email]>:
The problem is known, we have a bug report about it. This component comes from a KF5 / KDE library and does not work under Windows at this point. Find a unused keyboard shortcut, you can sort the list by keyboard shortcut and then click reassign.

Maik

Am Di., 30. Juni 2020 um 11:51 Uhr schrieb Thomas D <[hidden email]>:
OK. Could this be the reason why nothing is shown about the conflict? I mean, that there isnt really an actual conflict for Ctrl+E in digikam, but the conflict is in a default shortcut to some other KDE application? Problem is, this is Windows - not KDE - so I do not have any other KDE apps. So maybe this is a false positive?

Just trying to clear up what to report if this is to be reported to KDE bugzilla.


Den tir. 30. jun. 2020 kl. 10.08 skrev Gilles Caulier <[hidden email]>:
Thomas,

Well, this shortcuts dialog do not come from digiKam code, but from
KDE Plasma API which checks with all desktop active shortcuts. We
don't maintain this code. For all feedbacks, this must be done through
KDE bugzilla in KF5 KXMLGUI framework

Best

Gilles Caulier

Le mar. 30 juin 2020 à 03:40, Thomas D <[hidden email]> a écrit :
>
> OK. I guess this will help. However, when trying to assign a short cut key, I am faced with this UX problem:
> I try to find a key combo to open file manager.
> I have now tried a handful different combos, but everyone seems to be already assigned. So I am seeing this warning:
>
>
> The warning says that the chosen shortcut conflicts with the following combination: and then there is nothing after the colon.
> I should be able to see what other shortcut I am about to overwrite.
>
> Also, the text on the buttons seem rather ambiguous. "Reassign" I would think means: "OK, I see that my chosen shortcut was already used, so I will reassign that". But this is not what it means. Instead it seems to really mean "Overwrite the existing shortcut with your new shortcut."
> But if I do this, then I break some unknown existing shortcut (without intention of doing that) and leaves me no way of knowing what  shortcut just got overwritten.
>
> Also, the dialog offers no help in finding a vacant shortcut combo. For example, if I say Ctrl+E and that is taken, the program could easily try some "neighbouring" shortcuts like Ctrl+Alt+E, Ctrl+Shift+E, Alt+Shift+E, etc. and suggest some of these instead.
>
>
>
>
> Den tir. 30. jun. 2020 kl. 01.59 skrev Gilles Caulier <[hidden email]>:
>>
>> This can be customized by end users :
>>
>> Go to Settings/Configure Shortcuts/Open File Manager/Change Keyboard Shortcuts.
>>
>> Best
>>
>> Gilles Caulier
>>
>>
>>
>> Le lun. 29 juin 2020 à 23:12, Thomas D <[hidden email]> a écrit :
>> >
>> > If that is the intention, then I think it should be much easier to open a file manager (and a terminal!) on a given album. And it should preferably have a keyboard shortcut.
>> > Right now it is possible to rightclick on an album in the tree view and open in file manager, however, that is actually a very complex action:
>> > 1. Move the mouse to a tiny icon
>> > 2. Right click
>> > 3. Locate the "open in file manager" action on the list of possible actions in the right click menu
>> > 4. Click the Open in file manager action.
>> >
>> >
>> >
>> >
>> >
>> >
>> > Den man. 29. jun. 2020 kl. 20.04 skrev Maik Qualmann <[hidden email]>:
>> >>
>> >> That is the intention. What you see in the thumbnail view comes from the
>> >> database, which is created by a scan. You can open an album with a file
>> >> manager to see the actual content. You can also add unknown mime types, as an
>> >> image, video or audio file and then display them as a generic icon. But
>> >> digiKam will not be able to display a preview or the like.
>> >>
>> >> Maik
>> >>
>> >> Am Montag, 29. Juni 2020, 21:25:55 CEST schrieb Thomas D:
>> >> > Hi,
>> >> >
>> >> > Digikam does not show any non-image files in album view nor does it seem
>> >> > there is an option to have it show non-image files. This is quite annoying
>> >> > since often mobile phone images contain the image file plus a side-car file
>> >> > like img_2655.aae or maybe there are just some other files in the folder.
>> >> > This can lead to unexpected data loss when the user deletes an album that
>> >> > looks to be empty when viewed in Digikam but was in reality not empty. I
>> >> > think there should at least be (an easy) way of toggling whether non-image
>> >> > files are shown or not. They can just be shown with a completely generic
>> >> > file icon as thumbnail.
>> >> >
>> >> > I tested this on DK 7.
>> >>
>> >>
>> >>
>> >>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Peter Albrecht
In reply to this post by Thomas D
Hi,

as for "unexpected data loss" when deleting an album, please have a look at this
bug report: https://bugs.kde.org/show_bug.cgi?id=216412

It suggests to show a warning message before album deletion when directories
contain files which are not shown by digiKam.

In my usecases this warning message would be quite sufficient, since my albums
do not contain other file types in 95%.

Regards,
        Peter

On 29.06.20 21:25, Thomas D wrote:

> Hi,
>
> Digikam does not show any non-image files in album view nor does it seem
> there is an option to have it show non-image files. This is quite annoying
> since often mobile phone images contain the image file plus a side-car file
> like img_2655.aae or maybe there are just some other files in the folder.
> This can lead to unexpected data loss when the user deletes an album that
> looks to be empty when viewed in Digikam but was in reality not empty.
> I think there should at least be (an easy) way of toggling whether
> non-image files are shown or not. They can just be shown with a completely
> generic file icon as thumbnail.
>
> I tested this on DK 7.
>
> BR
> Thomas
>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Thomas D
Hi Peter,

Thanks for the link. So this is a > 10 year old bug that causes unexpected data loss that is confirmed but not fixed?
Having non-image files in an album is very common if you use Apple products. Because Apple often creates some sidecar files with various metadata in them. And you do NOT want to lose those files if you will edit the files later on an Apple product.
Also, I typically create a text-file with the same name as the image file but with .txt as extension in which I write notes about the image.  These can be extremely valuable for me. I simply to not understand the resistance to helping users not lose stuff like that...



Den søn. 5. jul. 2020 kl. 12.10 skrev Peter Albrecht <[hidden email]>:
Hi,

as for "unexpected data loss" when deleting an album, please have a look at this
bug report: https://bugs.kde.org/show_bug.cgi?id=216412

It suggests to show a warning message before album deletion when directories
contain files which are not shown by digiKam.

In my usecases this warning message would be quite sufficient, since my albums
do not contain other file types in 95%.

Regards,
        Peter

On 29.06.20 21:25, Thomas D wrote:
> Hi,
>
> Digikam does not show any non-image files in album view nor does it seem
> there is an option to have it show non-image files. This is quite annoying
> since often mobile phone images contain the image file plus a side-car file
> like img_2655.aae or maybe there are just some other files in the folder.
> This can lead to unexpected data loss when the user deletes an album that
> looks to be empty when viewed in Digikam but was in reality not empty.
> I think there should at least be (an easy) way of toggling whether
> non-image files are shown or not. They can just be shown with a completely
> generic file icon as thumbnail.
>
> I tested this on DK 7.
>
> BR
> Thomas
>
Reply | Threaded
Open this post in threaded view
|

Re: Digikam not showing non-image files in album view

Remco Viëtor
On dimanche 5 juillet 2020 17:00:40 CEST Thomas D wrote:
> Hi Peter,
>
> Thanks for the link. So this is a > 10 year old bug that causes unexpected
> data loss that is confirmed but not fixed?
Only one person (two with the duplicate report) felt it was important enough
to follow up on developer questions (not the original poster, nor any of the
20 or so support voters). That makes it *very* low priority...

> Having non-image files in an album is very common if you use Apple
> products. Because Apple often creates some sidecar files with various
> metadata in them. And you do NOT want to lose those files if you will edit
> the files later on an Apple product.
But if you remove the album *with all image files in it* you do NOT need those
sidecars anymore. And if you moved the image files out of the album prior to
deletion, you already most likely have lost the link between image file and
sidecar, again making the latter worthless. This is certainly the case for raw
files, which should not be written to (that's a good way to lose data as
well).

(...)
> I simply to not understand the resistance
> to helping users not lose stuff like that...

And this makes you sound like a troll...

Remco