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 115335 - FIle Roller abuses nautilus context menus.
FIle Roller abuses nautilus context menus.
Status: RESOLVED OBSOLETE
Product: file-roller
Classification: Applications
Component: general
2.3.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
: 529172 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-06-17 06:33 UTC by Dave Bordoley [Not Reading Bug Mail]
Modified: 2008-06-02 16:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dave Bordoley [Not Reading Bug Mail] 2003-06-17 06:33:41 UTC
File Roller is abusing the nautilus context menus.

The number of items that can appear in a context menu before it becomes
useless is around 10.

File roller adds "Add to Archive" to every files context menu. I'm willing
to guess that over 50% of gnome's user base (probably more even) never use
this feature. Furthermore, it is much more intuitive to add files to
archive via dnd to a viewed archive. This should be removed.

"Extract to subfolder" and "extract to" in the context menu of archive
files are unneeded. If a user wishes to extract a file to a subfolder, they
should use nautilus to create a new folder, dnd the archive to the folder
and use extract here. The same is true for "extract to," the user should
use nautilus to move/copy the archive to the folder they wish to extract
the file to, and use "extract here". Its somewhat absurd that a file
manager would have a feature that uses a file selector.
Comment 1 Paolo Bacchilega 2003-06-17 17:18:55 UTC
>File roller adds "Add to Archive" to every files context menu. I'm
>willing
>to guess that over 50% of gnome's user base (probably more even)
never >use
>this feature. Furthermore, it is much more intuitive to add files to
>archive via dnd to a viewed archive. This should be removed.

I don't agree here, there are users that don't want or can't use dnd
so you can't make a feature available only via dnd.

>"Extract to subfolder" and "extract to" in the context menu of >archive
>files are unneeded. If a user wishes to extract a file to a
>subfolder, they
>should use nautilus to create a new folder, dnd the archive to the
>folder
>and use extract here. The same is true for "extract to," the user >should
>use nautilus to move/copy the archive to the folder they wish to >extract
>the file to, and use "extract here". Its somewhat absurd that a file
>manager would have a feature that uses a file selector.

I think we can remove "extract here" and "extract to subfolder", on
the other hand "extract to..." has to remain because it is the most
general command and with it you can perform the other two operations.
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2003-06-17 22:15:41 UTC
"extract to" is just absurd, why would i use a file-selector (a poor
replacement for a file manager) from within a file manager.

"Add to Archive" is the wrong ui for this task. What you want is the
ability to open an archive file and cut/copy and paste a file into the
archive (direct manipulation).

Seth, Calum any other comments?
Comment 3 Murray Cumming 2003-06-24 17:29:25 UTC
> I don't agree here, there are users that don't want or can't use dnd
> so you can't make a feature available only via dnd.

He explained how you can do it without DnD.

However, I've generally used "extract to subfolder" because I'm not
sure whether the archive already has a sub folder or whether it will
spew a hundred files into the top of my home directory. I'd rather
just have an "extract" feature that created a subfolder if necessary.
In the rare case that people wanted it to spew lots of files directly
into the folder then they could move them there.

Comment 4 Dave Bordoley [Not Reading Bug Mail] 2003-06-25 11:39:08 UTC
Murray i claim in that case than that you should do 

file->new folder, dnd the file to that folder and extract it there.
Though if in a subfolder is a better default that we should just do
that by default. Just don't prompt the user for further input if you
can avoid it.
Comment 5 Paolo Bacchilega 2003-06-25 18:15:16 UTC
The difference between "Extract here" and "Extract to..." is just one
more click, because after selecting "Extract to..." the extract dialog
sets the directory where the archive is as the default directory;
furthermore "Extract to..." lets you set the extraction options.

I don't think the user we are targeting can perform an extraction of
an  archive in a folder different from the one the archive is in
without the "Extract to..." command.  The sequence of operations you
are suggesting is too much complicated.

I don't like "Extract in a Folder" command because i'm sure no one can
guess what will happen just reading the command name.

"Add to Archive..." is usefull for creating new archives: say you want
to zip a directory in an archive, with "Add to Archive..." you have to
right click on the directory, select "Add to Archive..." and specify
an archive name; without this command you have to open File Roller,
select "New", specify an archive name, select "Add", navigate the file
selector untill you find the directory you want to zip, press Ok,
close File Roller. Judge yourself which is simplier (note that you
have to use the gtkfileselector in both cases).

So my preferred solution is "Add to Archive..." for all file types and
"Extract to..." for archives.

Comments?
Comment 6 Dave Bordoley [Not Reading Bug Mail] 2003-07-05 17:12:00 UTC
ccing campd. We had a conversation about this in irc awhile back.
Comment 7 Murray Cumming 2003-07-15 07:15:28 UTC
I think the main problem now is the awfully complicated dialog box
that comes up when you choose "Extract To ...". That's really a
different FileRoller bug.
Comment 8 Paolo Bacchilega 2003-07-16 09:23:06 UTC
we can keep the "destination folder" option always visible and add a
"more options" togglebutton that hides/shows the other options.
Comment 9 Jens Knutson 2003-09-17 02:10:46 UTC
I think "Extract here" is a superior solution to "Extract to..." in
this case.  Context menus are designed for speed and efficiency -
having to wait for another dialog to pop up (it does take a moment or
two), and then read the options to make sure you aren't doing
something you don't intend, etc, is a lot more hassle than just "Right
click on file, left click on 'Extract here'".

Paolo does point out that "Extract to..." offers the user more
options, without abusing the context menu, but for those that want
different extraction options, can't they just double-click and open
File Roller's main UI for that stuff? :-)
Comment 10 Seth Nickell 2003-09-17 19:40:00 UTC
A much better solution is to have double-clicking on archives perform
the option that people want 95% of the time: to extract the archive in
the current directory ala "tar -xvzf". Just popup a simple progress
bar dialogue when they double click, and then get rid of it when done.
The only tricky thing is you may need to detect if there's only one
item at the top-level of the archive. If there's only one item
(typically a folder) you can go ahead and extract, otherwise you
should put it in a sub-dir with the same name as the archive being
extracted sans extensions.
Comment 11 Calum Benson 2003-11-27 17:21:08 UTC
Well, personally, I'd be more than happy if I only had the ability to:

- Double-click an archive to open it in File Roller (as now, since I
almost always like to see what's in an archive before I unpack it...
and it's consistent with the 'double-clicking always opens a new app
or window' model of spatial nautilus)

- Drop/paste files onto an archive file (or into an open file roller
window) to add them to the archive (accessible, since copy/paste is
accessible via the keyboard... and File Roller itself has an Add Files
menu item, which is accessible too)

- Select one or more files in nautilus, and create a new archive from
them in the same directory.

All of which by my reckoning requires just one file-roller related
menu item: File->Create Archive from Selection (or something), which
you might also want to put on each file/folder's context menu.  No
need for Add to Archive or Extract To at all :)
Comment 12 Dave Bordoley [Not Reading Bug Mail] 2003-11-28 06:30:32 UTC
Well calum my initial opinion on this issue is that nautilus should 
be able to edit archive files like special folders, since 99% of your 
typical archive editting matches 99% of typical file management, so 
why the need for a special gui? Just double click on the file and get 
a "folder" view of it.

However, I usually go with seth's suggestions since i respect him as 
a designer so...

In regards to creating new archives, i'd much prefer a tar.gz 
template file being available either from templates folder or some 
type of new menu, but this is getting a little sci fi futurish i 
suppose.
Comment 13 Olivier Le Thanh Duong 2005-10-27 01:53:31 UTC
> Well calum my initial opinion on this issue is that nautilus should 
be able to edit archive files like special folders, since 99% of your 
typical archive editting matches 99% of typical file management, so
That's viewing Archive as VFS, older version of Gnome did that I think (and
Windows still does). I never really liked that since it the cause of recurrents
bugs when a file opened from the archive depends of other file also contained in
the archives. e.g. a set of Html files with images and like between them.
The answer to that is to get every app use the same vfs but even whithout being
pessimistic, I don't think it's going to happen soon.

this bug is not closed, so I don't know if it is a general fix or not but on
Ubuntu Breezy they have removed all options but "Extract here". (well I don't
like it but that's not the point)

So can we close the bug or not?
Comment 14 Paolo Bacchilega 2006-10-21 17:43:57 UTC
file-roller does not abuse the nautilus context menu any more (there is at most one entry) so I close this bug.
Comment 15 Paolo Bacchilega 2008-06-02 16:34:03 UTC
*** Bug 529172 has been marked as a duplicate of this bug. ***