> In order to perform more advanced tasks, such as to change the content of the
> archive, one would merely have to double click on it, perform the file management tasks, and
> then rearchive it.
It's not "merely", it's actually a pretty complicated and resource intensive task, whereas right clicking on the archive for the few times where you really need it to be extracted is simple and doesn't hog resources like needlessly decompressing and re-compressing a file each time you want to check or read its contents. Detecting and remembering the compression method used for an archive (including the options used, which isn't trivial) is not an easy task, and I fail to see how people new to computers will deal with that.

> There are situations where this would not be an efficient method, such as for very
> large archives, but these situations are very unlikely to arise for the vast majority of users.
Who are you to decide what is "likely" to arise to the vast majority of users? If you can't find compeling arguments to justify the many problems this behaviour is going to cause, please don't resort to extrapolating your own preferences and deciding "most people" have the same use case you have.


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

Please don't dismiss the concerns of everybody in this thread as if they just need to "try it". We already try it everyday we deal with archives - and I can tell you, the amount of times I need the archive to be extracted in a folder and the original archive destroyed represents 1/10 of the times I deal with archives. The rest of the times, either I need to check 10 other archives first to find the one I need to decompress, or I just need to read one (or a few files) file inside the archive.

>> 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.

Nope, it's confusing and introduces an useless overhead - why would we ask users to decide a good directory to uncompress the archive (they would also need to check there's enough free space, and check how much space the data would hold _uncompressed_) when they can just double click on it and access its contents?

The method of decompressing any archives before you can see what's inside, access it and work on it sounds more like a bad understanding of what you can do with archives. You can access, view, work with and archive content and modify it _without_ having to decompress it to a folder.

>>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.
Our experience, combined with what we see users do, points to the contrary. And we were all "newbie" at first, and we can remember how we used archives before (at least if we started computing with graphical interfaces when others were stuck with DOS ;) ).

>> 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.

That's the worst answer in this thread so far... "The user can cancel the process at any time..."
Hoging user's resources and offering that wonderful "solution" is in which way so much better than just opening the archive for him and let him get his job done?