| Summary: | Renaming options only seem to persist if more than 1 image is selected | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Roland <carbonwerkes> |
| Component: | AdvancedRename-dialog | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 8.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Roland
2025-07-05 08:43:54 UTC
Tested under MacOS and behavior is fully reproducible with 8.7.0... I remember this being reported as a bug before. But it's intentional. Individual renames aren't meant to flood the rename history. As I said, it was definitely programmed that way. Gilles, if you want to change it, just say so. Maik Im not following. If I have to manually select from the history pulldown the template to apply, and that is the most recent template, it doesnt add additional history entries. In fact, it doesnt change the order of history- it seems to simply identify that the template exists in history, so any further history op is aborted. Shouldnt the history box reflect the order of template use as most recent to least? Regardless, in any context- if I pull down history, or paste in the template manually from the clipboard, or recreate it manually, the net result is the same- no change to the history pulldown. Worse, the case where there is an addition is if I get the template wrong. There doesnt seem to be an easy way to delete a template usage from the history list (at least not in that modal window), so seems to be having one that is not wanted simply adds more chance for inconsistency. No history is saved for a single image. It's only added to the history after two or more images. In my workflow, it's actually the case that my individual renaming is usually drastically different from group renaming, and I don't need it in the history. This behavior was probably even requested as a bug report. Developing an option to delete history entries is something to consider. Maik Maik talk probably of this entry closed as INTENTIONAL : https://bugs.kde.org/show_bug.cgi?id=462825 Perhaps a better approach then would be to include a checkbox to the left of the template/rename box, where you have a conventional rename box and the existing variant, with one or the other hidden based on the state of the check box. Simply force the checkbox to selected if multiple files were selected. The checkmark could just be 'Template Mode' or something like that... This is the then Bug 211060. Andi Clemens explained the single filename in a comment at https://bugs.kde.org/show_bug.cgi?id=211060#c8 And here is the code: https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/advancedrename/advancedrenamedialog.cpp?ref_type=heads#L330 Here the pattern is deleted so that it is not included in the history: https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/advancedrename/advancedrenamedialog.cpp?ref_type=heads#L362 And no, no additional option to complicate things even further. It's either/or. Maik Well, as I see it, there isnt anything wrong with the history approach per se. The problem with the implementation is that its not listed as most recent. It is listed as chronological- as a function of when that pattern was created. So, re-using it for a single image doesnt move that pattern to the top of the history box, which is not at all typical for a file history/recents implementation. And so looking through a list of potentially similar patterns, especially if you have a single image in a directory where you dont have reference to the 'standard' being used for that branch or tree, seems like it could be more user friendly. Could the history box be sorted by last used, so that it is more like a recents/history vs something like an alphabetical listing of export formats etc? I think I'm misunderstanding something. The most recently used renaming pattern is always at the top. If you select and apply a pattern from the middle of the list, that pattern will be first in the next renaming. Maik Well, I dont know if you are misunderstanding anything- but perhaps for whatever reason we arent seeing the same result. It is possible there is a bug where if there are 10 entries in history, it simply stops appending or reordering. In my instance, I have exactly 10 items in the history list, which I believe is the hard-coded limit. If I create some new pattern, it isnt added to the list. If I hit F2 for a single file, and select say, Item 3, from the list, annd OK that, the list on next access doesnt show former item 3 as item 1- it remains as item 3 in the list. I dont see a way in the dialog box, or in the System-wide Settings, to either clear this history, or to configure it to shed items from the list etc. So yea, perhaps there is just some weird thing going on with history once 10 items are persisted. R |