| Summary: | falls behind multiple delete operations, leading to error messages | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Ch. Eigler <fche> |
| Component: | geeqie | Assignee: | Michael Schwendt <bugs.michael> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | bugs.michael |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-09 19:36:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Quoting from: http://sourceforge.net/tracker/index.php?func=detail&aid=2900032&group_id=222125&atid=1054680 | I think that everything works as designed: delete operation does not block | the gui and the list of displayed files is updated after the operation | finishes, so by holding the delete key you managed to press it twice on the | same file and the "another operation in progress" message is correct. | | I am not sure if we want to change this. In the future we want to use | virtual filesystems, where the delete operation can take really long time, | so changing it back to synchronous operation probably does not make sense. | | Anyway, the recommended way of deleting multiple files is to select them | first and delete them at once. [...] Since Geeqie development has stalled in 2010 officially (with the main developers taking a break and a few contributors working on private git repos in various places), it isn't anything where a fresh discussion would result in changes. |
When browsing a directory full of JPG's, and liberally deleting them (in safe-delete / trash-can / no-confirmation mode), geeqie often falls behind the user. If we hit DEL DEL DEL fast, to zap the next three pictures, the second and/or third often pop up a dialog box: This operation can't continue: file or directory does not exist Closing that dialog box in turn requires the canceling of yet another dialog box. So much work just, because we were too fast for the program. It is as if the DEL's are attempted to be handled without the sort of enqueuing effect that gqview used to do. geeqie-1.0-10.fc15.x86_64