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 |
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. |
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 |
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. >> >> >> >> |
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 : |
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. >> >> >> >> >> >> >> >> |
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, |
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. 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: Den tir. 30. jun. 2020 kl. 13.20 skrev Maik Qualmann <[hidden email]>:
|
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 > |
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, |
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 |
Free forum by Nabble | Edit this page |