Comment 34 for bug 389176

First of all, thanks SY for supporting my case.

On Thu, Jun 25, 2009 at 6:51 AM, Julian Lam <email address hidden> wrote:

> Specific user-cases also apply which this solution cannot account for:
> 1. What if the user double-clicks an archive which can be read, but its
> parent folder cannot be written to?

The solution would be to display the "Extract archive to..." dialog.
Displaying a "Cannot write to directory" message does not help the user the
least.

2. What if the user is using the archive as a form of compressed storage,
> opens the files within on the fly, and does not require the contents to be
> extracted? This would present an extra menu to access, when traditionally,
> there would be none.

I find this more of a corner case. The changes I suggest to file-roller
behavior need to be user-tested, and draw conclusions only afterward. My
theory is that users rarely do this. If a lot more users want to extract the
archive with photos they received from a buddy, without editing or
selectively accessing the archive it makes some sense to consider them as
well, especially if they account for a larger % of the userbase,

>
> 3. As previously mentioned, what if the archive is several gigabytes in
> size?
>

> You may be considering adding a conditional... perhaps "default to file-
> roller when archive > 1GB". This is a terribly inelegant solution, and
> just adds another layer of complexity to an otherwise simple program.

Why would you add such a conditional? The user can cancel the process at any
time if he figures that it takes too much time. If he wants to extract an
archive a gig in size, let him.

Let's not change a thing.

I kind of understand this resilience to change, but please let's just
user-test this and see where it takes us.