Written by Emper the 14 Sep 10 at 22:29.

I've come up with an idea of how the GUI could look like:


It's also possible to add an "Extract all" option in the menu and "Extract selected" in the context menu.

If the progress field is a bad idea maybe you could add the progress to the popup and display both current and total progress. And estimate time if that's possible.

You could also add the ability to shutdown (if running as root) or any other command when the queue is finished. Or mayble display a message or play a sound.

I'd also like the option to "Add to queue" from the default context menu so you don't have to find all the files via "Open". And also drag-and-drop archives to the left list.

I've come up with an idea of how the GUI could look like: <img alt="File Roller" title="File Roller" src="http://img571.imageshack.us/img571/2610/2rz8dy0.png" /> It's also possible to add an "Extract all" option in the menu and "Extract selected" in the context menu. If the progress field is a bad idea maybe you could add the progress to the popup and display both current and total progress. And estimate time if that's possible. You could also add the ability to shutdown (if running as root) or any other command when the queue is finished. Or mayble display a message or play a sound. I'd also like the option to "Add to queue" from the default context menu so you don't have to find all the files via "Open". And also drag-and-drop archives to the left list.

Written by ubumpi the 17 Sep 10 at 20:59.

As I see it this should be tested while split is very quick operation so this gives a significant speed improvement to compress huge files eg. backups. This ought to be rather simple task for any programmer while both split and compression (and tar) are already solved problems and the only thing is to tight these two together.

As I see it this should be tested while split is very quick operation so this gives a significant speed improvement to compress huge files eg. backups. This ought to be rather simple task for any programmer while both split and compression (and tar) are already solved problems and the only thing is to tight these two together.

Written by Akerbos the 18 Sep 10 at 10:58.

Instead of using some workaround, use an algorithm that can be parallelized.

Instead of using some workaround, use an algorithm that can be parallelized.

Written by arckeda the 20 Dec 08 at 22:55.

Ubuntu Brainstorm was updated in January 2009. Since the idea #16690 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #16690 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by mynoduesp the 28 Dec 09 at 01:13.

Include more notifications e.g. percentage complete, elapsed time, estimated time remaining, average ratio

Include more notifications e.g. percentage complete, elapsed time, estimated time remaining, average ratio

Written by vektor the 28 Dec 09 at 08:41.

By default display only progress bar. Provide a button "Details" that displays all the details from Solution #1.

(Inspiration: file copy dialog in Win7)

By default display only progress bar. Provide a button "Details" that displays all the details from Solution #1. (Inspiration: file copy dialog in Win7)

Written by pepperpupper the 15 Oct 08 at 10:32.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14420 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14420 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by marci003 the 29 Oct 08 at 18:22.

Archive should be extracted to temp directory if that situation requires it

Archive should be extracted to temp directory if that situation requires it

Written by nikos the 7 Oct 10 at 16:09.

after looking for a better and faster solution in compress process, I think that for a comun user like me, it would be more simple if we could have the chance to decid, after the compress process is completed, if we want to send it by mail or not.

the decision would be taken by a dialog box (yes or no), showed after the compress process.

thank you for your attention and aportations.

after looking for a better and faster solution in compress process, I think that for a comun user like me, it would be more simple if we could have the chance to decid, after the compress process is completed, if we want to send it by mail or not. the decision would be taken by a dialog box (yes or no), showed after the compress process. thank you for your attention and aportations.

Written by Kata1yst the 9 Oct 10 at 16:35.

Just what the solution says! If you haven't used 7-zip on a Windows machine, there is simply an entry in the right click menu titled "7-zip" (We'd title this "compress file" or something else fitting) which when clicked on, drops a menu with several useful options (For Ubuntu it'd be something along the lines of "Compress to .tar.gz", "compress to .zip", "add to existing archive" etc). This way we could add usability without cluttering the already cluttered right click menu.

Just what the solution says! If you haven't used 7-zip on a Windows machine, there is simply an entry in the right click menu titled "7-zip" (We'd title this "compress file" or something else fitting) which when clicked on, drops a menu with several useful options (For Ubuntu it'd be something along the lines of "Compress to .tar.gz", "compress to .zip", "add to existing archive" etc). This way we could add usability without cluttering the already cluttered right click menu.

Written by ActionParsnip the 22 Oct 10 at 16:26.

Nautilus can already do this if you add the script properly. You could have this in the deb for some of the rar packages if nautilus-scripts are enabled

Nautilus can already do this if you add the script properly. You could have this in the deb for some of the rar packages if nautilus-scripts are enabled

Written by Chocwise the 6 Nov 09 at 15:51.

Before extracting an archive, File Roller should check the contents for an execute bit and warn the user if there is one and maybe list which files have an execute bit.

Before extracting an archive, File Roller should check the contents for an execute bit and warn the user if there is one and maybe list which files have an execute bit.

Written by Chocwise the 6 Nov 09 at 15:56.

Before unpacking archives, Archive Manager should ask the User if executable bits should be stripped off of included files.
That Opion should be pre-checked, so that one can not accidentally forget about it.

Before unpacking archives, Archive Manager should ask the User if executable bits should be stripped off of included files. That Opion should be pre-checked, so that one can not accidentally forget about it.

Written by Lachu the 7 Nov 09 at 18:55.

Nautilus should have unpack/install software option and all other unpack options should drop executable bit.

It very intuitive for new users. If I have downloaded software, I wanna install it. In other cases I only need to unpack files.

It will be non-intuitive for admins, which will make backup of whole system(with executable too).

Changes will be done only in GUI. Console tools shouldn't been touched.

Nautilus should have unpack/install software option and all other unpack options should drop executable bit. It very intuitive for new users. If I have downloaded software, I wanna install it. In other cases I only need to unpack files. It will be non-intuitive for admins, which will make backup of whole system(with executable too). Changes will be done only in GUI. Console tools shouldn't been touched.

Written by sybiam the 12 Nov 09 at 08:28.

I'm not for "pre-selected option to remove all executable bits". Honestly by default, the extract manager should extract file like it always did. Keep the old behaviour but warn the user before sounds good to me.

The user should be warn about executables files. It should list all executable files. Then give you the choice.

a) continue with default behaviour
b) continue with removed executable bits
c) do not warn me again and save the current selected behaviour.

But I do find it usefull to extract without executable bits...Sometimes people on windows archive files but on windows everything is executable. This is not exactly a problem.

on the list of file. I'd also see a "checkbox" allowing only certain files to be executables.

I'm not for "pre-selected option to remove all executable bits". Honestly by default, the extract manager should extract file like it always did. Keep the old behaviour but warn the user before sounds good to me. The user should be warn about executables files. It should list all executable files. Then give you the choice. a) continue with default behaviour b) continue with removed executable bits c) do not warn me again and save the current selected behaviour. But I do find it usefull to extract without executable bits...Sometimes people on windows archive files but on windows everything is executable. This is not exactly a problem. on the list of file. I'd also see a "checkbox" allowing only certain files to be executables.

Written by mikropolip the 3 Dec 09 at 03:40.

Today there is no standard of executable files distribution under Linux. For example, NVIDIA distributes drivers in *.sh files on it's official website. Not only there is no gpg signature but they don't even bother to publish a checksum.

As long as there are already some proxy servers that can on-the-fly implant malware into *.sh files it is a great security risk to run nvidia installator even if it was downloaded from official website.

Linux world has already solved a problem of executables distribution by implementing signatures and checksum checks. But, since you need to heavily use console to properly check the files, this solution became fairly unpopular amongst desktop users.

What I propose is standard, a unified way to distribute executables with a checksum and GPG-signature. Unified, so It can be implemented in a GUI front-end. So, as AndrewLuecke mentioned, Ubuntu will be able to warn users when they run programs for the first time about where they were downloaded from, if they are digitally signed, considered safe, etc.

And if executable is not digitally signed or shipped in not standard(as I mentioned above) way not only should Ubuntu give a deadly warning but also a hyperlink to a comprehensive help-file which will clearly describe how insanely dangerous is to run such file.

Today there is no standard of executable files distribution under Linux. For example, NVIDIA distributes drivers in *.sh files on it's official website. Not only there is no gpg signature but they don't even bother to publish a checksum. As long as there are already some proxy servers that can on-the-fly implant malware into *.sh files it is a great security risk to run nvidia installator even if it was downloaded from official website. Linux world has already solved a problem of executables distribution by implementing signatures and checksum checks. But, since you need to heavily use console to properly check the files, this solution became fairly unpopular amongst desktop users. What I propose is standard, a unified way to distribute executables with a checksum and GPG-signature. Unified, so It can be implemented in a GUI front-end. So, as AndrewLuecke mentioned, Ubuntu will be able to warn users when they run programs for the first time about where they were downloaded from, if they are digitally signed, considered safe, etc. And if executable is not digitally signed or shipped in not standard(as I mentioned above) way not only should Ubuntu give a deadly warning but also a hyperlink to a comprehensive help-file which will clearly describe how insanely dangerous is to run such file. If Canonical will make a standard then Software distributors such as NVIDIA will catch up and start to distribute their files in a proper way. No one would want such a warning before Ones software execution. And, yes, Im talking about some simple standard, such as tar.7z archive with executable file, signature and maybe some supplementary information in it. And maybe with some custom file extension.

Written by cudjoe the 24 Jul 08 at 14:04.

Ubuntu Brainstorm was updated in January 2009. Since the idea #11476 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #11476 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by v1nce the 16 Oct 08 at 00:10.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14440 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14440 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!