Heiko Tietze wrote:

CTown wrote:I like how simple dealing with archives is in Mac OSX...

I would hate this behavior. When I load a compressed file from the web it is usually placed at /tmp often using a 'hash' name, and would be extracted into /tmp/8s7fzes87fr/ by Ark. Much better fitting to my workflow is Krusader's (or rather kio?) krarc: the archive is virtually opened at its place letting me decide what to do with the content and where to place the selected files.

/tmp is usually mounted to RAM in most distros. So, extracting an archive to /tmp wouldn't have any negative effects (like extra SDD writes for files the user never wanted). Also, /tmp is usually cleared at system shutdown (if it's mounted to the RAM). If the files are extracted then Ark can be rebased off Dolphin KPart and use Dolphin's views.

The purpose of the behaviour I described is to help out users who don't understand what an archive is. For instance, say a user went to bandcamp.com or jamendo.com to get free music legally. There is an option to download the whole album as an archive. The user might not know what "archive" and "extract" mean. Some users might also be confused while an entirely different file explorer opened up just to look for the music files. This way the user now has the "original file" even if they don't understand how to use it and a folder full of music that is actually usable after clicking on the archive.

Wow, that is one old bug report.

Tromzy wrote:If I may suggest something : it would be great to have multiple selection and extraction. What I mean is : currently if I select more than one files in an archive, and try to drag and drop them to a Dolphin window for extraction, only the last file selected is extracted. It would be nice if Ark extracted all the selected files.

This is a known issue which is currently being fixed.

enoop wrote:What ever happened to the changes listed in this blog post? http://lamarque-lvs.blogspot.com/2013/06/my-work-in-basyskom.html

I'm afraid there is still a lot of work to do in that branch...

Btw, as promised I started to work on the config dialog for Ark. You can follow the status of the patch and see a couple of preview screenshots here.

elvisangelaccio wrote:Btw, as promised I started to work on the config dialog for Ark. You can follow the status of the patch and see a couple of preview screenshots here.

Great, having a config dialog definitely makes sense. I just posted a review of the UI on the review request.

colomar wrote:

elvisangelaccio wrote:Btw, as promised I started to work on the config dialog for Ark. You can follow the status of the patch and see a couple of preview screenshots here.

Great, having a config dialog definitely makes sense. I just posted a review of the UI on the review request.

Thanks again. If you could also give a UI review to this other patch I would be really happy!
It's about the dialog for creating a password-protected archive.

elvisangelaccio wrote:If you could also give a UI review to this other patch I would be really happy!

To start with a positive statement: the dialog is okay In general. But it's always hard to review a screenshot only. Usability is about who is the user, in what situation she applies a feature, and what is the goal at all. I'd say creating an archive is the primary goal with the addition/goody to secure it. I would expect to get the option for password protection during the compression, like some kind of expander that shows your password panel. But maybe a checkbox 'password protected' makes it more trustworthy since collapsed content could be still active.
What I didn't understand from your screenshot is the part with encryption of files. Why is the checkbox disabled? (Should be clear from the UI, perhaps via tooltip).
Finally, please take a look on the placement guidelines. Your (disabled) checkbox must not the be the left most control, and there are no good reasons to have big margins (left hand space). If you want to left align the group (for what reason?), just make the container smaller.

Alignment HIG: https://techbase.kde.org/Projects/Usabi ... /Alignment

Heiko Tietze wrote:I would expect to get the option for password protection during the compression, like some kind of expander that shows your password panel. But maybe a checkbox 'password protected' makes it more trustworthy since collapsed content could be still active.

I agree. The password fields should only be shown if the user checks an "Encrypt archive" checkbox first, otherwise users may think that they always have to enter a password, even if they don't want to encrypt their archive.

What I didn't understand from your screenshot is the part with encryption of files. Why is the checkbox disabled? (Should be clear from the UI, perhaps via tooltip).

Indeed the "Encrypt also the list of files" is definitely going to be difficult to understand for most users. For me the question is: Is there a relevant usecase where people may want to encrypt the individual files, but leave the list unencrypted? Unless there is a good reason for doing that, I'd just always encrypt the list if the archive as such is encrypted.

Finally, please take a look on the placement guidelines. Your (disabled) checkbox must not the be the left most control, and there are no good reasons to have big margins (left hand space). If you want to left align the group (for what reason?), just make the container smaller.
Alignment HIG: https://techbase.kde.org/Projects/Usabi ... /Alignment

Indeed, no need for the left margin here.

Once questions have been answered here, we will post an "official" review on reviewboard so that others reviewing the patch can see our comments as well.

Thank you both. About the points you discussed:

- The password fields definitely needs to be shown only if required. I took inspiration from Gnome's file-roller dialog and indeed they do implement this behavior.
- The "Encrypt also the list of files" checkbox comes from the file-roller's dialog. The 7z and rar formats can only encrypt the entries content (i.e. Ark asks the password only if the user clicks an entry to preview/extract it) or both entries content and archive's header, i.e "the list of files". The latter implies that Ark needs to ask the password whenever the user opens the archive, in order to show the list of files. This can be considered a relevant use case: a user may want to open an archive just to check its content, without being bothered for a password. On the other hand, the zip format is only able to encrypt the entries content. That's why if the user chooses the zip plugin, the checkbox is disabled.
While this topic could be summarized in a tooltip for the checkbox, I think the best way would be a proper explanation in the Ark's handbook.
-Alignment: the HIG page was very useful, I fixed it. Thanks again.

elvisangelaccio wrote:Thank you both. About the points you discussed:
- The password fields definitely needs to be shown only if required. I took inspiration from Gnome's file-roller dialog and indeed they do implement this behavior.

To be honest, file-roller isn'd doing that well It has an "Other options" expander which than has a password field, so users can only guess that entering a password means that the archive is password-protected. Having a checkbox "Protect archive with a password" which when checked would show these options would make that explicit.

- The "Encrypt also the list of files" checkbox comes from the file-roller's dialog. The 7z and rar formats can only encrypt the entries content (i.e. Ark asks the password only if the user clicks an entry to preview/extract it) or both entries content and archive's header, i.e "the list of files". The latter implies that Ark needs to ask the password whenever the user opens the archive, in order to show the list of files. This can be considered a relevant use case: a user may want to open an archive just to check its content, without being bothered for a password. On the other hand, the zip format is only able to encrypt the entries content. That's why if the user chooses the zip plugin, the checkbox is disabled.

Ah, okay. Complicated stuff... I fear that many users won't understand what this does, but currently I don't see an easy way to explain it.

While this topic could be summarized in a tooltip for the checkbox, I think the best way would be a proper explanation in the Ark's handbook.

Explaining that whole thing in a tooltip would certainly be too much, but what's a must from my perspective is to write e.g. "The zip file format does not support encrypting the file list, but only the content of the files", based on the type. That way, users know what's happening.
See the tooltip HIG: "If the control is disabled, add a short explanation about the reason to the tip."

-Alignment: the HIG page was very useful, I fixed it. Thanks again.

Can you post a screenshot of the reworked layout?

I have no posted a complete UI review on reviewboard with a summary of what we discussed here plus further comments.

colomar wrote:

elvisangelaccio wrote:Thank you both. About the points you discussed:
- The password fields definitely needs to be shown only if required. I took inspiration from Gnome's file-roller dialog and indeed they do implement this behavior.

To be honest, file-roller isn'd doing that well It has an "Other options" expander which than has a password field, so users can only guess that entering a password means that the archive is password-protected. Having a checkbox "Protect archive with a password" which when checked would show these options would make that explicit.

- The "Encrypt also the list of files" checkbox comes from the file-roller's dialog. The 7z and rar formats can only encrypt the entries content (i.e. Ark asks the password only if the user clicks an entry to preview/extract it) or both entries content and archive's header, i.e "the list of files". The latter implies that Ark needs to ask the password whenever the user opens the archive, in order to show the list of files. This can be considered a relevant use case: a user may want to open an archive just to check its content, without being bothered for a password. On the other hand, the zip format is only able to encrypt the entries content. That's why if the user chooses the zip plugin, the checkbox is disabled.

Ah, okay. Complicated stuff... I fear that many users won't understand what this does, but currently I don't see an easy way to explain it.

While this topic could be summarized in a tooltip for the checkbox, I think the best way would be a proper explanation in the Ark's handbook.

Explaining that whole thing in a tooltip would certainly be too much, but what's a must from my perspective is to write e.g. "The zip file format does not support encrypting the file list, but only the content of the files", based on the type. That way, users know what's happening.
See the tooltip HIG: "If the control is disabled, add a short explanation about the reason to the tip."

-Alignment: the HIG page was very useful, I fixed it. Thanks again.

Can you post a screenshot of the reworked layout?

Sure. Here you go: http://abload.de/img/fixed-alignmentonkdz.png

I will post some updated screenshots on ReviewBoard, once I address all the issues.

elvisangelaccio wrote:Sure. Here you go: http://abload.de/img/fixed-alignmentonkdz.png

I will post some updated screenshots on ReviewBoard, once I address all the issues.

Thank you for sharing the screenshot, and I'm glad you did, because there was a little misunderstanding
We did not mean that the checkbox label should be on the left side of the checkbox. In fact, we explicitly advise against doing that (though admittedly, we'll have to make that more explicit in the HIG). What we meant was that the checkbox and its label should be moved a little more to the right (like the "Delay" and "Rate" labels and sliders here), but still the label should be on the right of the checkbox.

And also the space between the left border and the labels of the password fields should be reduced, like in this example:


I'm sorry for putting you through so much extra work, but consistent form alignment really helps an overall more polished look.

Don't worry, your suggestions are very welcomed

EDIT:

Here the updated screenshots:

1. https://share.kde.org/public.php?servic ... ca8f05133e
2. https://share.kde.org/public.php?servic ... 6c199e794a
3. https://share.kde.org/public.php?servic ... c014b7a8b8
4. https://share.kde.org/public.php?servic ... 69f0c614a8
5. https://share.kde.org/public.php?servic ... a61a77c7a1

Any news about these new features?

noric wrote:Any news about these new features?

Most of them have already been implemented. Any feature you were looking for, in particular?

elvisangelaccio wrote:

noric wrote:Any news about these new features?

Most of them have already been implemented. Any feature you were looking for, in particular?

Mostly: drag and drop multiple files, external viewers.

I'm using Ark 2.19 with KDE 4.14.2 (Mint 17.1, based on Kubuntu 14.04 LTS). Is there a way I can backport the latest Ark?
Thanks for your efforts.