Bug 729371 - falls behind multiple delete operations, leading to error messages
Summary: falls behind multiple delete operations, leading to error messages
Alias: None
Product: Fedora
Classification: Fedora
Component: geeqie
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-09 17:31 UTC by Frank Ch. Eigler
Modified: 2011-08-09 19:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-09 19:36:27 UTC

Attachments (Terms of Use)

Description Frank Ch. Eigler 2011-08-09 17:31:44 UTC
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.


Comment 1 Michael Schwendt 2011-08-09 19:36:27 UTC
Quoting from:


| 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.

Note You need to log in before you can comment on or make changes to this bug.