GNOME Bugzilla – Bug 169369
Extract dialog selects child folder of working directory by default
Last modified: 2005-05-03 02:21:32 UTC
Please describe the problem: If I open an archive in Fileroller and click extract, the Extract dialog opens with the first directory in the current directory selected. This means that if I just click "Extract" on the dialog, the files are extracted to whatever directory comes first in the sort order, rather than the directory containing the archive as I would expect. The only way to extract to the current directory is to navigate up one directory in the hierachy and select the current directory. Steps to reproduce: 1. double click on an archive 2. click "extract" on the toolbar 3. click "extract" on the dialog Actual results: Files are extracted to first child directory of the current directory Expected results: Files are extracted to current directory Does this happen every time? Yes Other information: This is with Fileroller 2.9.92, gtk 2.6.4 in Ubuntu Hoary.
I can confirm this behaviour - in Ubuntu Hoary too. And more this is propably gtk file-selector bug because the same behaviour is in sound juicer and other applications.
*** Bug 171015 has been marked as a duplicate of this bug. ***
*** Bug 171110 has been marked as a duplicate of this bug. ***
Definately a usability problem IMHO. There's a strong ambiguity when looking at the dialog and trying to determine whether the extract action will act on the currently open folder vs the currently selected folder. It's been suggested that file-roller should be using a Save-type dialog instead of an Open-type dialog. In a save dialog, the first entry is not automatically opened. This would solve the issue. Possible complication: Would this present a conflict with the extra options currently used in the Extract dialog? Are these options really neccesary? The 'selected files" option could be implied from whether or not file are selected, the manual files text box is awkward at best, recreation of folders should probabbly just be assumed, overwriting files could be done via a dialog on a file-by-file basis (with a "for all the rest as well..." option), and the password prompt should really stay away until needed.
It's also been pointed out that the same behavior does affect other apps, esp. in cases where it is not a 'Save'-type operation. Rhythmbox, for example, uses the Open dialog to select a folder to import, and therefore suffers the same select-child-instead-of-open-folder issue. Perhaps something should be changed at the GTK level of both the save and open dialogs to make this behavior clearer to the user?
This is actually one of the most unnerving bugs I have eperienced in a while. In general I have really appreciated the quality work that has gone into file-roller. But this bug greatly reduces it's usefullness-and the above listed work around is simply non-discoverable for inexpeienced users. select-child-instead-of-open-folder *is* appropriate for an 'open' dialog but non-sensical for a 'save' dialog. I am sure there is some good reason why the 'open' dialog from GTK was used for the extract function of file-roller. But I cannot see the default open dialog for all GTK applications being adapted to account for cases where the 'open' dialog is being used inappropriately. Is it not possible to add the 'extra' functionality to the 'save' dialog ? Please help resolve this issue quickly -perhaps cross posting to GTK bugzilla-this effects usability sufficiently to render programs which exhibit this bug unusable by inexperienced users(and even some who are)...
a slight addition: the 'open' and 'save' dialogs have a distinct form and size aside from their obviously different functionality. 'extract' is logically associated with 'saving'. Utilizing a dialog which one already associates with 'opening', due to the similarity in form and size between the extract dialog and the 'open' dialog, to extract files has a very negative impact on the visual- cues, recognition and retention which are interwoven in our UI* usage and underpin our normal interaction. It's an issue of self-same consistency and properly a part of HIG**. *I am not UI specialist. **perhaps such should be cross posted to the HIG folks
The save action is used to save a file thus the save dialog will ask the user for a filename, this makes no sense in the extract dialog where the user has to choose a folder. I think a filechooserbutton is the less wrong solution.
*** This bug has been marked as a duplicate of 171885 ***