To be honest, I don't see the need to change the behaviour of file-roller/nautilus.
In the end, it comes down to each user's individual user preferences, and what he/she does with archives immediately after downloading.
Here are my specific user cases:
1. Installing a piece of software - usually involves the command line, and thus "tar" is invoked in the command line, bypassing this issue altogether.
2. Looking at individual files in an archive, as in the case of manuals and/or picture collections
Specifically, there have been times when blindly extracting into a subfolder is not ideal, either due to permissions problems, or the general lack of a need to. If I'm just going to look at one file in an archive, I don't need the rest of the support files, especially if they're readme files or other superfluous files.
The best use, in my opinion, is the one that's already in place. File-roller decompresses the archive in its viewing mode, but doesn't extract the files anywhere, saving on unnecessary hard/flash drive wear and tear. If need be, file-roller also functions excellently as a drag-and-drop client, allowing you to open a destination folder in another window (or the same nautilus session, if you so wish), and extract the file there directly.
If I double-clicked on an archive and had the entire archive dumped into a subfolder, I'd have to clean up everything that remains once I'm done with the contents. Why should I, when I could have avoided this "mess" (and I use that term conservatively) in the first place?
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?
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.
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.
File-roller appeals to the lowest common denominator - by just showing you the files, and essentially saying "what do you want me to do with them?"
To be honest, I don't see the need to change the behaviour of file-roller/ nautilus.
In the end, it comes down to each user's individual user preferences, and what he/she does with archives immediately after downloading.
Here are my specific user cases:
1. Installing a piece of software - usually involves the command line, and thus "tar" is invoked in the command line, bypassing this issue altogether.
2. Looking at individual files in an archive, as in the case of manuals and/or picture collections
Specifically, there have been times when blindly extracting into a subfolder is not ideal, either due to permissions problems, or the general lack of a need to. If I'm just going to look at one file in an archive, I don't need the rest of the support files, especially if they're readme files or other superfluous files.
The best use, in my opinion, is the one that's already in place. File-roller decompresses the archive in its viewing mode, but doesn't extract the files anywhere, saving on unnecessary hard/flash drive wear and tear. If need be, file-roller also functions excellently as a drag-and-drop client, allowing you to open a destination folder in another window (or the same nautilus session, if you so wish), and extract the file there directly.
If I double-clicked on an archive and had the entire archive dumped into a subfolder, I'd have to clean up everything that remains once I'm done with the contents. Why should I, when I could have avoided this "mess" (and I use that term conservatively) in the first place?
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?
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.
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.
File-roller appeals to the lowest common denominator - by just showing you the files, and essentially saying "what do you want me to do with them?"
Let's not change a thing.