| Summary: | Advanced rename: keep the pattern | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Bartek Pietrasiak <pietras.sp> |
| Component: | AdvancedRename-dialog | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | languitar |
| Priority: | NOR | ||
| Version: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.0.0 | |
| Sentry Crash Report: | |||
|
Description
Bartek Pietrasiak
2009-10-19 11:58:59 UTC
Yes, I was thinking about a combobox with at least 5 last used patterns. About keeping the pattern: I guess most users don't like it, but we will see. But a history combobox should definitely help you out here. Ok right now I have a huge problem :) I use a modified KLineEdit here to insert tokens, highlight them etc. This can not be done with an editable KComboBox widget, so right now I have no clue how to add a dropdown menu with history items. The only solution I see so far is copying the kcombobox class from KDE and modify it. Why, you don't use auto-completion ? It work very well... It's not enough ? Gilles Like this : http://lxr.kde.org/source/extragear/graphics/digikam/libs/widgets/common/searchtextbar.cpp#68 KLineEdit will provide combobox menu if necessary... Gilles You mean for history? Hmm I can try it... otherwise I will reimplement KComboBox. The API is weird there, we have a KComboBox::cursorPosition() method, but no KComboBox::setCursorPosition(). This would have solved my problem I guess. yes, for history... Gilles "I guess most users don't like it" I think that most people like this digikam feature and miss it in e.g. gimp. It is quite useful when you edit more than one file. I don't have to change the input data while resizing, sharpening and saving to jpg. In this case it might not be so important, since I don't rename as often as resize ;) Btw, if you wanted to make both of the groups happy, you can put a checkbox in the options ;) The "problem" is that I just added another request about using the filename as a pattern when only a single image is going to be renamed. It would be very inconsistent if many files will restore the last pattern, but a single file will use the filename as the pattern. So I guess a history function is much more practical, since we can set the filename as a pattern for single rename, but you are still able to restore your last patterns by a dropdown menu. Both sides should be happy then... at least I guess so :D SVN commit 1037602 by aclemens: Add history to the AdvancedRenameWidget. Some issues: - Highlighting is not working correctly anymore, somehow the CSS style is ignored (if you move the mouse very quickly, a token sometimes is colored red, but only for some milliseconds). - The lineedit widget seems to be overlaying the ComboBox, I have not found yet a way to make it fit Bartek, can you test this and tell me if it is enough for you? CCBUG:211060 M +91 -33 advancedrenameinput.cpp M +38 -4 advancedrenameinput.h M +21 -4 advancedrenamewidget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1037602 History is implemented now and should work fine. A maximum of 10 patterns will be remembered. Gilles, somehow the history / combobox is broken in BQM? I don't understand why. Any idea? Andi Right now the history is saved in AdvancedRenameWidget (which made sense to me), but I'm thinking about moving it out into the places where the widget is used, e.g. CameraUI, AlbumUIDialog and BQM. Every one of these instances will then have it's own history. What do you think? Hmm I will go with this setup now: Every instance (CameraUI, AlbumUI and BQM) remembers the their last renaming string and inserts it as the active pattern. The history will be shared though. This should satisfy the original poster as well. I'll close this wish now, feel free to add more comments if necessary. It is fine for me. Thx. |