After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 97609 - Drag and drop seems to work erroneously
Drag and drop seems to work erroneously
Status: RESOLVED DUPLICATE of bug 102501
Product: file-roller
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
: 156492 160653 303538 309231 312090 318105 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-11-04 06:57 UTC by sdiconov
Modified: 2006-05-07 21:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description sdiconov 2002-11-04 06:57:16 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.
Comment 1 John Spray 2004-04-21 19:33:47 UTC
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.
Comment 2 Kurt Erickson 2004-06-04 08:55:05 UTC
>-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.
Comment 3 Jeremy Brown 2004-07-13 20:06:25 UTC
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.
Comment 4 Vincent Noel 2004-10-27 15:00:26 UTC
*** Bug 156492 has been marked as a duplicate of this bug. ***
Comment 5 Joseph Daly 2004-11-22 15:30:11 UTC
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).
Comment 6 Vincent Noel 2005-01-04 16:43:12 UTC
*** Bug 160653 has been marked as a duplicate of this bug. ***
Comment 7 Wouter 2005-01-05 10:46:05 UTC
> 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?
Comment 8 Mark Florian 2005-02-11 10:36:46 UTC
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?
Comment 9 Johannes Hölzl 2005-06-07 19:30:35 UTC
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.
Comment 10 markush 2005-08-10 20:28:59 UTC
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.
Comment 11 Haru 2005-11-03 20:50:24 UTC
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?
Comment 12 Geoffrey Pursell 2005-12-02 17:03:46 UTC
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?
Comment 13 Teppo Turtiainen 2006-03-18 10:55:43 UTC
*** Bug 303538 has been marked as a duplicate of this bug. ***
Comment 14 Teppo Turtiainen 2006-03-19 18:08:35 UTC
*** Bug 312090 has been marked as a duplicate of this bug. ***
Comment 15 Teppo Turtiainen 2006-03-19 20:09:20 UTC
*** Bug 309231 has been marked as a duplicate of this bug. ***
Comment 16 Teppo Turtiainen 2006-03-19 21:05:33 UTC
*** Bug 318105 has been marked as a duplicate of this bug. ***
Comment 17 Bartek Kostrzewa 2006-03-28 11:32:57 UTC
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 :)
Comment 18 Luke Hutchison 2006-03-28 15:51:37 UTC
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).
Comment 19 Fabio Bonelli 2006-04-12 08:33:48 UTC

*** This bug has been marked as a duplicate of 102501 ***