QArchiver - A new multi platform graphical Archiver

[Simon Berger]

Hi guys,

Maybe you already read somewhere that I am working on a new multi- platform archiver. It runs on Windows, Linux and OS X and could be build for some mobile systems (with limitations).

Maybe you ask if there is really the need of yet another archiver. I want to share my points.

1) In my view there are only three archivers serious for daily use 7zip, PeaZip and Winrar (maybe also WinAce) but they are all very similar and don't provide much new things
2) Only PeaZip is multi platform ported (but not on OS X yet)
3) There is no really good archiver on Mac OS X
4) I wanted to create a new big project and trying QT

Some facts:
The archiver will be created with the use of the QT framework and the 7zip/p7zip library surely in C++. It will very most likely be a Open Source Application

In the first versions I will try to create a program that will work on every system more or less the same. Later I try to add platform independent things (context menu implementation in windows...).

Whats already in:

- A file system / Archive view thats switchable between the normal one level view and a tree view that includes files (see atachment)
- Every archive that's supported in 7zip can be opened like a folder in this view (also archives in archives)
- Only picket files can be extracted from an archive out of all folders

What I am planning:

- Don't use message boxes for errors (not much error handling yet) because I think that theses message boxes are a very annoying instrument to show errors. Instead use a log box like in Visual Studio in compiling or something like browsers for blocked popups.
With this system it's possible to also view many warnings
- extract whole archive if open executable files inside.
- extract archives with a queue (most done already)

I wrote the post to maybe get some new ideas or create a good discussion

Edit:
The name QArchiver is only the project name until I what it will be final.

[osmanturan]

I hope, you will do good job at the end. IMO, all of GUI archivers look like same. And most of office/home users don't know the correct meaning of archivers. I have lots of funny stories about them. So, best thing for me, keep the archiver as much as user-friendly. Some estimations and some tips in the archiver would be very useful too. So, in the end, you should support both expert and novice users with two different interface. All of these ideas are already planned for BIT. So, you have to make it as soon as possible

For mobile platforms, I highly advice to limit required memory. Most of pocket PC have 64-128 MiB RAM. And most of users don't know the meaning of closing application in a Windows Mobile platform (actually it's some kind of hiding). So, free memory is always low. Also, a light codec (slug, thor, lzss like with filters) can be good too. Because, they are battery powered device and I personally don't want to waste too much time with a compression/decompression process.

- extract whole archive if open executable files

Note that, this is already supported by WinRAR

Edit: As a note, most of files which can be opened in pocket PC are small. So, leaving a huge dictionary for a LZ codec is bad IMO. even 4 MB can be high.

[m^2]

I hope, you will do good job at the end. IMO, all of GUI archivers look like same. And most of office/home users don't know the correct meaning of archivers. I have lots of funny stories about them. So, best thing for me, keep the archiver as much as user-friendly. Some estimations and some tips in the archiver would be very useful too. So, in the end, you should support both expert and novice users with two different interface. All of these ideas are already planned for BIT. So, you have to make it as soon as possible

For mobile platforms, I highly advice to limit required memory. Most of pocket PC have 64-128 MiB RAM. And most of users don't know the meaning of closing application in a Windows Mobile platform (actually it's some kind of hiding). So, free memory is always low. Also, a light codec (slug, thor, lzss like with filters) can be good too. Because, they are battery powered device and I personally don't want to waste too much time with a compression/decompression process.

Note that, this is already supported by WinRAR

Edit: As a note, most of files which can be opened in pocket PC are small. So, leaving a huge dictionary for a LZ codec is bad IMO. even 4 MB can be high.

I'd say that all specialized archivers look the same. A file manager is usually an archiver and most look different from specialized ones.

Thor doesn't decompress fast (in lzp modes) and slug doesn't excel here either.

[Simon Berger]

I hope, you will do good job at the end. IMO, all of GUI archivers look like same. And most of office/home users don't know the correct meaning of archivers. I have lots of funny stories about them. So, best thing for me, keep the archiver as much as user-friendly. Some estimations and some tips in the archiver would be very useful too. So, in the end, you should support both expert and novice users with two different interface. All of these ideas are already planned for BIT. So, you have to make it as soon as possible

Thanks for your kind words. Yes that was my point. most archivers haven't much features. Thats very surprising because WinRar for example is really old on the market. Also they try to be a file manager but really can't provide whats necessary to be used like this.
Yeah you hit the most important point with the brdige between expert and novice users. For the start I have the plan to focus on "normal users" providing things that are easy to see while using the program.
I think the message system is a very important point. For example to inform the user why the whole archive will be extracted on executable files.

For mobile platforms, I highly advice to limit required memory. Most of pocket PC have 64-128 MiB RAM. And most of users don't know the meaning of closing application in a Windows Mobile platform (actually it's some kind of hiding). So, free memory is always low. Also, a light codec (slug, thor, lzss like with filters) can be good too. Because, they are battery powered device and I personally don't want to waste too much time with a compression/decompression process.

Yes I am aware of this so I added the limitated comment. It would also woul also be an addition in the style of main program only supporting some well known formats for extraction and zip and maybe slug if it goes Open Source. I have no plans to introduce an own format at the moment but for mobile platforms this could be really nice.

Note that, this is already supported by WinRAR

Yes thanks. I know . But WinRar isn't really the product I want to "replace" because it is too expensive for the limited additional features it provides over 7zip.

[osmanturan]

Most of home/office users don't like file managers and file managers like archivers. And they have really bad habit. I should give a true story about that which I frequently faced. Some office users really don't like to read any warning/error which is displayed. While describing something step by step for them at the phone, they always ignore that messages and they don't mention about that messages Here is the another story: my homemate frequently uploads some TV series to rapidshare as encrypted multi-volume RAR archives. And nearly quarter of people which have downloaded complain as the given password is wrong. They don't think whether they have downloaded any parts correctly or not. So, they only complain about that by ignoring the others' thankful messages in a forum

I agree that both slug, thor and any other compressors are not strong. But, what do you want to expect from a daily purposes? Note that, even today I use ZIP archives instead of RAR or 7-zip archives for compatibility reasons. And also most of people don't like PAQ-like compression actually. For example, my homemate frequently uses WinRAR and he's very happy with it. But, he agree that he will be more happy with >2500 KiB/sec compression speed. This is far from any PAQ series compressor - even any LPAQ.

[Simon Berger]

I agree that both slug, thor and any other compressors are not strong. But, what do you want to expect from a daily purposes? Note that, even today I use ZIP archives instead of RAR or 7-zip archives for compatibility reasons. And also most of people don't like PAQ-like compression actually. For example, my homemate frequently uses WinRAR and he's very happy with it. But, he agree that he will be more happy with >2500 KiB/sec compression speed. This is far from any PAQ series compressor - even any LPAQ.

No you misunderstood me. I love compressors like slug, thor and so on. I am not interested in any paq clones at all, only if they try to get the speed of lz77 compressors (in compression) while producing much smaller files (like ccm, m1 and in the last time also your bit ).
I only wanted to point out that I don't see the chance to introduce a new format into the world and so I focus on other things.
The only idea I had was to use bulats arc format because it is sometimes much better then lzma but first it isn't really stable and second there isn't a library or something similar to implemented it without much work. Maybe later

[osmanturan]

@Simon Berger: Previous post was for both m^2 and you For m^2, I tried to point out end-of-users don't need super strong compression at the cost of too much time. For you, I tried to point out how end-of-users can behave. Sorry for confusion As a note, I still think that BIT is far from practical usage unless I catch >1 MiB/sec processing speed

[m^2]

I totally agree that maximum size is rarely important. By default, I use 7-zip mx1 and intent to move to Slug X with FreeArc's multithreading when it's ready.

Possibly you misread my previous post, I didn't say that slug / thor are weak, but that they are slow when it comes to decompression - LZ77 is much better.

And I also think that speeding up BIT is the way to go.

[osmanturan]

I totally agree that maximum size is rarely important. By default, I use 7-zip mx1 and intent to move to Slug X with FreeArc's multithreading when it's ready.

Possibly you misread my previous post, I didn't say that slug / thor are weak, but that they are slow when it comes to decompression - LZ77 is much better.

Ahh...Then sorry. I misunderstood. But, I don't think >25 MiB/sec decompression speed is really necessary. Because, even my Asus based barebone laptop (Core2Duo 2.2 GHz, 2 GiB RAM, 5400 RPM HDD instead of 7200 RPM HDD for excessive heating) can't exceed this limit while file copying

And I also think that speeding up BIT is the way to go.

Yep. I'm working on it currently

[Vacon]

Hello everyone,

Hi guys,[...]
- extract whole archive if open executable files inside.[...]The name QArchiver is only the project name until I what it will be final.

I am a fan of OpenSource cross-plattform-programs. So good luck!

a) I'm not quite sure, if I like the idea of unpacking a whole archive containing 1000s of pictures only because I start pictview.exe. Why not leaving decision to users: starting xxx.exe -> dialog pops up "extract whole archive or just the choosen file?" [Checkbox] or "Only file" <-> "All". Or imagine software-compilations containing 100s of sfx-files... Why cluttering HDDs with all this unwanted stuff...? Leave it to user, please!

b) my second wish would be a 2-panel-view, similar to 7zFM.exe. Allthough DoubleCommander and CoolExplorer are good tools too

c) forgot to mention: why not staying with the name to QArchiver? Or do want to change to CrossArchiver?
Best regards!

[Simon Berger]

Hi Vacon,

a) Yes sure. I am planning to create a bunch of options . For this I thought of a message box with a check box to never show again.

b) Yeah also planned. You will be able to create two or maybe 4 views and can set every view to normal or tree or tree without files...

c) Do you like it? If I will do and get good feedback. Why not

[thometal]

I think the best GUI would be like 7zip but with an additional view in the bootom which represent the archive which will be created. like in Winace.

Why do you not use Gnome?
Most Linux distros came with Gnome.

[Vacon]

Hello everyone,

Hi Vacon,

Hi Simon!

a) Yes sure. I am planning to create a bunch of options . For this I thought of a message box with a check box to never show again.

b) Yeah also planned. You will be able to create two or maybe 4 views and can set every view to normal or tree or tree without files...

c) Do you like it? If I will do and get good feedback. Why not

a) be careful. The more options, the more confusion for newbies...
b) strike!
c) CrossArchiver? I won't stop you...

Best regards!

[Simon Berger]

a) Second this. But it's the job to wrap it nice. With this option message box the user will maybe create a default rule without using any bloated option dialog. Like what utorrent does here for example .

c) Sounds good. :-D. Will think about it.

[giorgiotani]

The screenshot of the tree view is nice, so far I like the polishedness of the design; the idea of queuing extraction tasks is good, allowing more rational usage of disk.

[Simon Berger]

Thank you. But polishedness. Is this meant to be positive? :-P
Anyway. Surely the date/time formating and many other this will be changed later. That really isn't important at this point.
I am at the moment working on the extracting thats really more complicated then I thought.

- All childs of a selected dir/archive have also to be selected/deselected but they have to be de-selectable one by one
- if a subfolder of a parent-selected-folder will be expanded the childs should be selected (because if you would decompress before they would be decompressed
- If the content of a folder wasn't showed it still have to be extracted

If anyone different opinion please post

[Simon Berger]

I am very unsure how I should implement the multi view. Let me listing the ideas I currently have.

1) Having only 2 views exactly like it is in 7zip and Winrar.
2) Having the possibility to open up to 4 views or 3 (one at the top and two at the bottom or in the other direction.
3) Something really complicated came in my mind today:
Creating as much windows (like in the attached screenshot) as you want with a tab bar but combining it with idea 2. I think of something similar to the plugin system of notepad++ or a normal tool window. The views should be dockable up to 4 inside the area and you can resize them like you want.
I know that all went straight to a file manager. Thats currently not my intention. But for such a big feature it's the best to implement it early. You also are able to only have one treeview/normal view without any windows.

The only question is if it makes sense to have such a tab view like in a browser in such a archiver or later also file manager. Would you use it?
(I try to get rid of this big window title bar and try to get something like a tool-window there...).

[Vacon]

Hello everyone,

I am very unsure how I should implement the multi view. Let me listing the ideas I currently have.[...] I think of something similar to the plugin system of notepad++ or a normal tool window. The views should be dockable up to 4 inside the area and you can resize them like you want.[...]
The only question is if it makes sense to have such a tab view like in a browser in such a archiver or later also file manager. Would you use it?
(I try to get rid of this big window title bar and try to get something like a tool-window there...).

Well, to be honest: Tabs aren't my favorite way to navigate (except inside FireFox). Don't ask me why...
In a way I'm conservative using commander-style file-managers. But that's my point of view. Maybe a well designed program can convince me...?
Will d'n'd be possible inside your tabs? What about hotkeys? How will they work if several windows are opened (how will they know where to copy/move/archive files)?

Best regards!

[Simon Berger]

Thats less complicated then if you have several views on one form. I only have to look for the one that has focus.
But yeah I am away from this tab thing and use 2-4 views. Maybe with the chance to put them off the form and have windows of them. But only maybe

[Simon Berger]

Fine. Next topic. As I already have written I almost implemented queued extraction. But I think it's a bad feature for people having more then one or even many hard drives and doing much extraction work.
I don't think that it would be easily possible to test from/on what hard drive the extraction runs so do you think an extraction management would be useful? Starting only one extraction but have the possibility to resort this queue or start manually more then one.
A second point is the temp extraction. The normal user don't really knows that he starts a extraction if he want to open a file inside or want to view an archive inside an archive. But I would pause all other extractions on this point and run this without the chance of doing anything on the GUI (the other extractions are non modal).

I have many ideas what I could do. But I am no one who much uses an archiver. Only for compress or decompress single archives. I am happy for any opinion

Ah and I forgot. I am not planning to support any queue for compression. You could create as many archives as you want and it also doesn't affect the extraction queue at all.

[Simon Berger]

Hi,
only a short newsflash.
The attached image shows 3 views side by side. Besides a better optic and nice splitting I haven't done much progress because of a heavy to find bug (maybe in Qt) which I know got rid of. The views can't work together at the moment in any way and surely I won't use 3 side by side. My plan is to give the possibility to place from 1 to 4 views in the following ways:

1. (2)

- -

2. (2)

 - 
 -

3. (3 Only one on the top and over the whole width)

 - 
- -

4. (3 Only one on the bottom and over the whole width)

- -
 -

5. (4)

- -
- -

But maybe there will only be up to two side by side or a single one. Because the other possibilities needs more internal changes. I also think what to do because of multiple monitors. Dunno what I could do to have a good support. I only have one so I couldn't really do experiments on this case.
I am now hoping for good progress to get a fully working extraction program out "soon".

[Simon Berger]

First a picture of the current developing progress



There you can see an included console for example.

I now start with the compression part and I surely want to use all the possibilities of 7z including multi format archives like ultra7z and and I think also PeaZip uses.
But I am no expert in the advantages and disadvantages of the algorithms. Beside normal compression profiles like LZMA, PPMD and GZIP I want to include:

- optimized (This should use lzma1 (or optional 2) ultra and ppmd for text)
- decompression speed (Most 7z but maybe gzip could be usefull. The use of algorithms has to change because of the selected ram usage)
- compression speed (dunno yet)
- brute force (later or never)

That's only what my simple mind invented yet Comments are welcome.

[Simon Berger]

A new picture of the moment



I included optimized compression as written in my last post. It comes close (300kb gap) to the totalized result of 7-Zip on maximumcompression.com
This might come from some special adjustments in the benchmark and/or LZMA2 instead of LZMA on some files.

The file separator in QArchiver puts them to 4 different blocks at the moment, 1 LZMA2
2 PPMD (every file into its own block)
3 LZMA + BCJ2
4 LZMA2 + Delta.

[Fallon]

Thanks for screen shots.
Some general remarks, for an Archiver's interface. If you can use it, or do better with a fresh approach, God bless...

-1-
The obvious. Make things work with as few clicks as possible, to archive and extract, for every way you want it.
-2-
For optimal Shell Integration, you could think of having the items from the right-click menu, available in the main window.
I am talking about buttons on the toolbar, working like the right-click context menu. For the right-click menu, it is more or less accepted, what is optimal. In main windows of Archivers, we see differences.

A quick look at some differences, that users have to entertain:
- 7-Zip:
to extract from an open archive to 'folder name', you have to go 'one-level-up' first. Not good.
- WinRAR:
when an open archive shows a closed folder, which is often the case, WinRAR cannot extract the files, without extracting this folder as well. You can argue that it is the perfect way to go, but both 7-Zip and Winzip can extract the files and leave the folder.
WinRAR DOES have TWO extract buttons on board, for its toolbar. Thus, WinRAR can put a folder around extracted files, without loss of time. When the user wants to add such a folder, he just hits the right button. It's the right-click menu in action, in the main window. Verdict: Good.
- winzip:
after years, I installed winzip again. It has improved, but for people who claim to pay attention to shell integration, some things remain to be done.
- more files are not added by default to a 'folder name' archive. You have to type, which is almost a crime for an intuitive interface.
They may have done this intentionally, to make users pack up the folder, whenever more files are involved. It takes a choice away, therefore: not good.
- positive are the view styles. This is worth a look! Files visible in a folder, can be extracted without the folder they are in.
- when files are just there to view, without a folder, winzip cannot add a folder during extraction, without loss of time. This is consequent, but again, the user has to type. I could go on about winzip (why does the main interface appear behind the necessary progress window, also when files are first added to a winzip job, etcetera), but for now, I feel a need to remove the product again.
- Freearc, Peazip: I will kindly stay away from projects I like, here.

-3-
Most users will just want to get a job done. Few, or no info messages, is good. Events just take up a users time. Few options in sight, when they are not wanted by the user, is also good.
-4-
Since the thought was raised in this thread: a second, wizard like, interface, is probably a bad idea, because it will annoy most users after a very short time.
-5-
To be user friendly, small size buttons could be avoided. Like in Browsers. Typical browsers, much used programs, do not have very small buttons.
Example: it will be user friendly to avoid a 'back' button, or 'one-level-up'button, which is so small that elderly people will hate it.

Shell integration probably ranks in the top ten of 'Important things for Archivers', right behind stability, compression and speed.
Done well, users will have to learn little about a programmer's hobbies in respect to the interface.

[Simon Berger]

-1-
The obvious. Make things work with as few clicks as possible, to archive and extract, for every way you want it.

That's absolutely the goal. Exact ideas are very welcome. I see you gave some.

-2-
For optimal Shell Integration, you could think of having the items from the right-click menu, available in the main window.
I am talking about buttons on the toolbar, working like the right-click context menu. For the right-click menu, it is more or less accepted, what is optimal. In main windows of Archivers, we see differences.

You mean buttons for extract to, extract to folder x and so on? Yes I learned some important points for a good GUI. There won't be anything only in right click menu.

A quick look at some differences, that users have to entertain:
- 7-Zip:
to extract from an open archive to 'folder name', you have to go 'one-level-up' first. Not good.

Something I will have in mind when I come to implement smaller usability features.
That's something the tree view you can see some posts back for. You can open any folder in any archive and then decide which files/folders you want to extract while seeing everything on the screen.

- WinRAR:
when an open archive shows a closed folder, which is often the case, WinRAR cannot extract the files, without extracting this folder as well. You can argue that it is the perfect way to go, but both 7-Zip and Winzip can extract the files and leave the folder.

How is this working with 7-Zip I couldn't find out. Maybe I misunderstood your point.

WinRAR DOES have TWO extract buttons on board, for its toolbar. Thus, WinRAR can put a folder around extracted files, without loss of time. When the user wants to add such a folder, he just hits the right button. It's the right-click menu in action, in the main window. Verdict: Good.

Must have -y yeah

- positive are the view styles. This is worth a look! Files visible in a folder, can be extracted without the folder they are in.

Possible in QArchiver too. (1. Extract all selected files to target in flat and tree view, 2. Extract from folder of first selected file 3. Extract from root folder).

-3-
Most users will just want to get a job done. Few, or no info messages, is good. Events just take up a users time. Few options in sight, when they are not wanted by the user, is also good.

Because you also named the browser. This really is an application which has the newest features and biggest evolution. I want to implement some kind of information bar you know for blocked popups...

-5-
To be user friendly, small size buttons could be avoided. Like in Browsers. Typical browsers, much used programs, do not have very small buttons.
Example: it will be user friendly to avoid a 'back' button, or 'one-level-up'button, which is so small that elderly people will hate it.

I guess up to now the buttons are very big (enough) .

[Fallon]

How is this working with 7-Zip I couldn't find out. Maybe I misunderstood your point.

I guess up to now the buttons are very big (enough) .

In 7-Zip, archive a 'test' folder with some files in it.
Open the 'test.7z' archive with 7-Zip file manager.
Open test folder as well, select files, hit Extract button. Test folder will not extract with the files.

As for the small buttons, it's probably a standard size. So,wherever these are unavoidable, having good visible icons is all important.

I have a finishing remark. The ideal way to archive, with a Graphical User Interface, is to select files and add to archive.
It may seem trivial, but in principle this is slightly better than to select a folder and add to archive.
Why? Because after adding just files, you can view the content in the interface, without the necessity to open a folder first.
A folder can be added during extraction, if it's wanted to avoid a mess.
That's why WinRAR's second extract button is right (saving time) and winzip's forced typing of a file-name -when adding just files- is wrong (costing time).

7-Zip's and winzip's option to extract the files from a folder, WITHOUT that folder, is a very neat addition to have, once a folder is present in an archive.
But it does not quite make up for the best way to make an archive.
Because, once a folder is present, a click is always necessary to get at the content. That's just a stubborn fact.

I'll take a hike now, before the men in white coats come rushing in. Will look in again later.