| Summary: | Renaming doesn't prevent from concurrent operation | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Bartek Pietrasiak <pietras.sp> |
| Component: | AdvancedRename-engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.0.0 | |
| Sentry Crash Report: | |||
|
Description
Bartek Pietrasiak
2009-10-23 00:00:50 UTC
No, renaming is a separate thread, otherwise the GUI will be locked (which most users don't want to have). Setting a progress bar is another thing (but needs indeep changes I guess, since move / copy actions also don't show a progress). Why is clicking on a tag give you strange results? What do you mean? Some files had the new name, some not. Some had the tag assigned, some not. And the dialog with, as far as I remember, "An unspecified error ..." or something like that. Renaming doesn't assign tags, so there must be something else going wrong. And the error messages come from KDE itself, I can't do anything about this. We use KIO::Job for moving / copying. About locking the UI while renaming: I'm not sure if users like this. For me it is also better as it is right now. I can rename images in a folder, go to another and start a new rename job. Otherwise I have to wait for the first job to end. Marcel, would it be easy to display the move / copy status in the statusbar? Right now we are not doing this, only for metadata changes. A progress dialog is shown in newer versions of digiKam. |