[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #10 from Roland --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #9 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #8 from Roland --- 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? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #7 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #6 from Roland --- 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... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #5 from [email protected] --- Maik talk probably of this entry closed as INTENTIONAL : https://bugs.kde.org/show_bug.cgi?id=462825 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #4 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 --- Comment #3 from Roland --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 Maik Qualmann changed: What|Removed |Added CC||[email protected] --- Comment #2 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 506620] Renaming options only seem to persist if more than 1 image is selected
https://bugs.kde.org/show_bug.cgi?id=506620 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #1 from [email protected] --- Tested under MacOS and behavior is fully reproducible with 8.7.0... -- You are receiving this mail because: You are watching all bug changes.
