[digiKam-users] Free floating albums list possible - or alternatively duplicate DK windows?

Mon Aug 8 10:01:37 BST 2022

Hello,

I am trying to improve the ergonomics of my workflow when importing a 
new batch of images into my photo collection.

*I have all my photos organized like this:*

/photos/<year>/<yyyy-mm-dd>-<album-name>

Where <yyyy-mm-dd> is the date of the particular photo session in the album.

*This is my workflow:*

I will move all photos from the kamera into the folder

I have all my photos organized like this:

/photos/<year>/in/<yyyy-mm-dd>

where <yyyy-mm-dd> is the /import-date/.

This folder will typically have hundreds or thousands of photos from 
several photo sessions.

I will now sort these into an album for each session as well as delete 
all photos that are too poor quality.

So the sub albums will then be something like

/photos/<year>/in/<yyyy-mm-dd>/<yyyy-mm-dd>-<album-name>

When I have done that, I will typically have dosens of albums in folders 
like <yyyy-mm-dd>-<album-name> all located in the <year>/in folder.

I will now have to move these into the actual photo collection for that 
year (ie. move them out of the "in" folder).

The way I do this is to drag the folder one by one onto the particylar 
<year> folder (parent to "in") via the Albums list.

The problem here is that the albums list is huge. It has several hundred 
albums in it. So for example when I am in 2022/in, I have to be very 
careful with the mouse while dragging each album to the parent folder.

The problem is exacerbated by the fact that  I can only move one album 
at a time. DK will not allow me to select several albums to move.

I can approach this in a different way, however: I can open the 'in' 
folder in my operating system file manager and then move the albums 
easily from there. Eg. by cutting and pasting them. Then I can do a 
refresh inside Digikam afterwards and DK will then see the original 
albums as having been deleted and discover the new albums as having been 
created. Problem here is obviously that then DK seems to miss all 
metadata about them such as tags, recognized faces, etc.

So I have been trying to improve the ergonomics here in two ways:

1. Tried to detach the albums list

2. Tried to open an additional application window

Neither of these approaches seem possible. Please see below

*Detached albums list*

I have been trying to figure out if it is possible to "detach" the 
albums view such that it is a free floating window that is not attached 
to the digikam main window.

What I mean is this part highlighted with red:

I think this is common functionality in many other complex applications 
such as for example Gimp, Photoshop, etc. that you can drag such parts 
of the application into separate windows in order to ease a particular 
workflow or to make it more ergonomic.

I think Gimp call this Dockable dialogs. Probably not the best name for 
the concept as these are not typically dialog windows...

Let me illustrate with an example from Gimp:

All the various visible parts of this application can be "docked" or 
"detached" from the main window.

See the one I highlighted with red.

I will now click and drag it:

See, I get this tool options for Brushes as a separate window.

*My question is: Can I do something to that effect on the Albums list in 
Digikam?*

If I can do this, how to do it?

If not? Can it be implemented?

How/where do I report this feature request?

I have tried searching bugs.kde.org for reported issues around this but 
was not able to find any. However, I must admit I have a really hard 
time navigating and searching bugs.kde.org.

I would love to report this as a bug, however, the bugs.kde.org 
interface was a bit confusing to me. It seems I must report this to a 
specific component of digikam. But I have no idea what component this 
should be for....

*Additional application window*

An alternative approach that could greatly improve the ergonomics of my 
workflow is to be able to open multiple DK windows.

This is functionality that is present in most common office applications.

Allow me to illustrate with an example from LibreOffice Writer:

Here we see a document opened in LO Writer:

I can click the /Window/ menu to get a new duplicate Window.

This will produce two identical windows that will allow me to view two 
different parts of the same document in parallel. This is highly useful, 
for example when you need to reference something in a different part of 
a large document.

*My question is: Is something to that effect possible with Digikam?*

If it is, how to do it?

If not? Can it be implemented?

How/where do I report this feature request?

**

-- 
Mvh
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wr0L7l4er86Yg4W7.png
Type: image/png
Size: 52101 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ic6k6X5J0rhGxSrs.png
Type: image/png
Size: 72432 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zRkrGuAyJeyH9AMV.png
Type: image/png
Size: 187319 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wmtp9BXv99MvLEPK.png
Type: image/png
Size: 26083 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d9Q08nKP8grplsDE.png
Type: image/png
Size: 5660 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220808/c3e6e529/attachment-0009.png>