GNOME Bugzilla – Bug 97609
Drag and drop seems to work erroneously
Last modified: 2006-05-07 21:42:08 UTC
When I drag a file from within an archive opened in file-roller to the desktop or any other place the program doesn not decompress it. Instead it shows "Adding to archive" message and sometimes complains about not being able to modify an archive stored on CDROM. The second attempt to do the same is always successful. The files do get uncompressed this time.
Here is my take on drag 'n' drop in file-roller: The most clear bug is that in order to drag an item to the desktop, one must drag it first over some of the listing space: dragging it directly sideways across the window boundary causes the program terrible confusion. Apart from that, the whole area of drag-drop has poor usability: -The "Extracting files" dialog pops up immediately upon initiating a drag: this shocks users. -Dropping an item back where it was picked up from does not cancel the operation as HIG suggests: it "moves" the item to its present location and then recompresses the archive to record this "change". -Drag-drop operations within an archive are committed immediately by uncompressing the archive, building the new tree and then recompressing it. Try that with a 30 meg bz2 archive and tell me if you still think it's a good idea. Although it would appear to be a design decision that one does not "edit and save" but simply edits, this is idealistic. The practicality of the tech involved means that you cannot work on these highly compressed archives in realtime.
>-The "Extracting files" dialog pops up immediately upon initiating a drag: this shocks users. I would like to second this, and more. I think that file-roller shouldn't begin decompression until the drag sequence has been completed (the sequence being: the mouse button is depressed, the mouse pointer is positioned over the destination, and the mouse button is released). The release of the mouse button represents the decision (command) to decompress: to allocate the disk space, and to use the cpu. That's how drag and drop works. Think of it as pressing return after typing a bash command. Decompressing before a button release gives users no chance to change their minds and is generally just insane policy. I think that this is easily the number one interface bug file-roller has. I really hope someone will fix it, it makes using file-roller a pain.
I've also noticed that sometimes after I drag and release the mouse button in, say, a Nautilus window, file-roller tells me that the operation has been cancelled. I can keep this from happening by holding down the mouse button over the Nautilus window while the files are being extracted, then letting up once the extraction is finished. At first I thought this was a UI decision (albeit a bad one), but after having the drag-and-drop extraction work correctly at least two or three times, it looks more like a bug.
*** Bug 156492 has been marked as a duplicate of this bug. ***
The problem is that all the file manager sees is a set of file names. When you drag and drop from file-roller, it needs to extract the files before it can give the file manager some names. Unless you are dealing with small files, extracting after the start of a drag and drop operation is not usable. The files in the archive need to be extracted before any drag and drop operation starts (when the archive is first opened).
*** Bug 160653 has been marked as a duplicate of this bug. ***
> it needs to extract the files before it can give the file manager some names. Does it really have to extract the files in order to give the file manager som names? There already is a file list I think?
WinZip doesn't display this insane behaviour (in Windows), and in fact every gui archive manager in Windows does drag'n'drop of files from an archive properly (that is, it deals with the request to extract files only after the drag is released). I'm pretty sure Ark in KDE can manage this properly as well. WinRAR on Windows opens enormous archives virtually instantly, so it clearly doesn't decompress the archive immediately upon opening the file. This is the kind of behaviour I expect from my archive manager. Why can't file-roller do it?
One possible solution would be to implement the XDirectSave protocol. http://www.freedesktop.org/wiki/Standards_2fdirect_2dsave But currently nautilus doesn't implement this protocol. If this is used the actions are reversed. For the user the same happends she or he drags the file(s) from the application to some target. But here the filemanagers sends the URI of the location to the application. This would allow to get the target location and store the extracted files via GNOME-VFS.
how about you hook a function to the drag and drop whose sole purpose is to spawn a dialog asking the user: Do you want to decompress the files: X A X I (scrollable list) X V to the directory: <drag and drop target> [yes] [no] the decompressing shouldnt start during the drag and drop process at all.
This bug is very annoying, it means drag and drop can't be used at all with large files or slow computers. But after reading this, I at least understand why the problem exists. I want to disagree with the comments above that say that decompressing shouldn't start during drag and drop, though - if the user has started dragging, then they want to extract the files, so why not make the process faster by starting as soon as the app knows this? To eliminate the "scare factor" of opening a progress dialog, why not move the progress indicator into the status bar of the main window, or hide it completely and extract quietly in the background?
Agreed: the current behavior is very bad. If this is a technicality with the way GNOME handles drag and drop, can we work around it? If the file object to be dragged needs to be "real," why not create a fake, empty, 0kb version of whatever file/dir is being dragged, and use that to complete the drop, then immediately stash it in /tmp or delete it and begin the "real" extraction? Beginning the extraction during the drag is well and good, but IMHO: - (MOST importantly) We should be able to release the mouse button before the extraction is complete without living in fear. Insanely annoying when your're extracting a large file/dir. - It would be nice (har har) if the extraction process/thread should have a somewhat decreased priority, at least during the drag, so the GUI remains very responsive - There should be no progress dialog that pops up as soon as you move the file off the main window. This is freaky. It's should appear once the user has released the mouse button and the drag is complete. But: are the time savings from beginning extraction during the drag really all that great? Is it worth it?
*** Bug 303538 has been marked as a duplicate of this bug. ***
*** Bug 312090 has been marked as a duplicate of this bug. ***
*** Bug 309231 has been marked as a duplicate of this bug. ***
*** Bug 318105 has been marked as a duplicate of this bug. ***
Wow... I've had a look through the source and while the app is nice and dandy I think that the way the files are extracted is the problem... if I understand correctly the files are extracted to a temporary directory and then nautilus (or whatever app receives the drag) moves or copies them from there? Here's my suggestion: as file-roller takes ages anyway to open an archive (I believe it decompresses it completely, reads all filenames and then deletes the temporary decompression) why not make it decompress the archive into a temporary directory and KEEP IT THERE. Now when files are dragged somewhere, there will be no decompression process to wait for before the file_list can be fully assembled to be passed to the receiver. Looking at the source I think this would be the most painless cure for the current problem plagueing it. PS: I've tried postponing extraction until file_list_drag_get or file_list_drag_end and this helps with the UI responsiveness, but since the only way to keep the UI from locking up and pausing the extraction is gtk_main_iteration() the receiver goes ahead and receives the incomplete list of files if the extraction process is not finished before the mouse button is released, so that's not very helpful. PPS: At least the "extract" buttons work as expected :)
Bartek: My understanding is that not all archives can be catalogued (listed) without extracting the entire archive. e.g. zip can, but tar.gz cannot (because the file list is spread through the entire archive). The nicest solution proposed so far is to implement XDS (comment #9).
*** This bug has been marked as a duplicate of 102501 ***