[digiKam-users] 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: image.png]




Den tir. 30. jun. 2020 kl. 13.20 skrev Maik Qualmann <metzpinguin at gmail.com
>:

> 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 <sdktda at gmail.com>:
>
>> 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 <
>> caulier.gilles at gmail.com>:
>>
>>> 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 <sdktda at gmail.com> 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 <
>>> caulier.gilles at gmail.com>:
>>> >>
>>> >> 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 <sdktda at gmail.com> 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 <
>>> metzpinguin at gmail.com>:
>>> >> >>
>>> >> >> 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.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200630/3c24ee40/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 37649 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200630/3c24ee40/attachment-0001.png>