There’s no obvious option.
Aha. Found it.
include album sub tree
Ooops → you’re correct! → this digiKam feature isn’t well documented …
There is a mention in the old KDE Forum and, a mention in the KDE mailing-list –
And, in the documentation it’s mentioned but, only as aside and, it’s not explained –
- The documentation topic is –
These settings allows to customize the tree views of the Left and Right Sidebar.
- In the “Batch Queue Manager” documentation –
If you want to process in a queue the items from an album and all sub-albums, just turn on the option to display sub-albums in the Album-View using the View ‣ Include Album-Sub Tree menu entry, and then select the corresponding items and add them to the Batch Queue Manager.
All in all, not really helpful –
- We may have to raise a Bug Report in the form of a Change Request to the digiKam documentation.
Who’s going to do it? → You?
@Franken14679, does documentation for the process exist? That’s the kind of thing that I might actually be able to assist with.
Very simple – create a new account at <https://bugs.kde.org/> – AFAIK the login for this Forum isn’t connected to the KDE Bugzilla.
Choose “File a Bug” → choose “Applications” → choose “digikam” → choose the Component “Documentation” and, choose your installed version of digiKam.
Leave the severity as “Normal” – select the distribution you’re using – select the OS (Linux??).
Enter a Summary of the issue being reported.
Fill out the Description of the issue being reported – it ain’t a software issue (no repair to the code needed) – it’s a Change Request against the documentation.
Ah, @Franken14679, I’m aware of how to report a bug - I’ve filed about 100. Thank you lots regardless. However, surely a “change request” as you refer to it is the equivalent to a pull request? I wasn’t certain of which GitLab repository to contribute to is all.
Nope. A “change request” is exactly what is says – it’s a (polite) request to have something changed.
- It’s actually a somewhat older term for what has become “Bug Reporting” – In the past and, currently, it was/is assumed that, anything that was produced by schooled craft people was either perfect or, acceptable –
It wasn’t implemented with a failure but, it should be changed to make it better …
There is a mindset that says – “We’re using the most up-to-date methods and tools – therefore, what we’re producing is perfect – failure free … ”
If you attempt to tell such a development team that, their code has bugs in it, they’ll usually be very upset, their combined egos are damaged and, they tend to ignore the report detailing the bug in their perfect, bug-free code.
How to work around this delicate issue?
- Submit a Change Request, politely requesting a change to the implementation which was presumed to be perfect …
BTW, as a software tester, I was submitting on average about 5 Bug Reports per day, based on the results of the Test Cases being executed – the managers of the software development teams were more than a little bit piqued because, each Bug Report referenced a specific (contractual) product requirement and, it described the product’s behaviour which wasn’t matching a specific requirement.
- When you’re testing against more than 2 000 contractual requirements, this is a fairly normal bug reporting rate …
Thanks, @Franken14679. Perhaps I’ll use that term when communicating with other, less receptive, teams of developers in future.