Review Request 123832: libarchive: Improve the handling of archive_write_header() errors.

[Thomas Pfeiffer]

> On May 17, 2015, 4:46 p.m., Raphael Kubo da Costa wrote:
> > I'm sending this review request to gather feedback from the usability group on the UI changes this patch makes:
> > * Dropping use of `archive_error_string()` in the error messages. While on the error messages become less precise, using that function adds a piece of English text coming from libarchive to user-facing messages that are translated and lead to an ugly mixture of English and other languages in the same sentence. Additionally, `archive_error_string()` possibly returns a string that make more sense to the programmer than to users. If this makes sense I may change other error messages that make use of that function too.
> > * The actual contents of the error messages. Are they good enough?
> > * The decision to stop extracting/compressing when the first error is encountered, even if it is possible to proceed. I'm doing this because currently there is no good way to show a series of errors in the UI.
> 
> Raphael Kubo da Costa wrote:
>     Ugh, the Markdown formatting of the previous comment got completely messed up and I am unable to edit or delete that comment. What's in italic is supposed to be one bullet point, and the final sentences not in italic are another one.

Thank you for involving us!

Now to your questions:

> Dropping use of archive_error_string() in the error messages. While on the error messages become less precise, using that function adds a piece of English text coming from libarchive to user-facing messages that are translated and lead to an ugly mixture of English and other languages in the same sentence. Additionally, archive_error_string() possibly returns a string that make more sense to the programmer than to users. If this makes sense I may change other error messages that make use of that function too.

I do not know exactly which strings that function returns, but I trust your judgment that these are probably mostly technical and therefore likely not useful to users anyway. I therefore support not showing them by default. What I think could make sense, though, is allowing users to show them on demand (e.g. with an expander), so that users who are either technically versed enough to understand it or who would like to paste it into their favorite search engine in hopes of finding help with their problem could do so.

> The actual contents of the error messages. Are they good enough?

Be aware that we usability people are mostly non-coders and therefore do not know where in the patch we find the messages. Could you please put the messages in clear text in the review request description or a comment? Thanks!

> The decision to stop extracting/compressing when the first error is encountered, even if it is possible to proceed. I'm doing this because currently there is no good way to show a series of errors in the UI.

This could be problematic. Imagine there is an archive with lots of important files in it, and one of them (or maybe an actually unimportant file in it) is somehow corrupted, causing an error. With the proposed behavior, it would not be possible to extract the other files anymore.

> I'm doing this because currently there is no good way to show a series of errors in the UI.

Would it be possible to continue extracting, collect all messages that occured and then show them all in one dialog at the end? If not, I'd rather ask they user after each error whether they want to continue extracting. this would make the process quite cumbersome if there are several errors but a user wants to continue anyway, but at least it would still be possible (and if a user just doesn't want to bother, they can still decide to cancel the extraction at the first error).


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123832/#review80528
-----------------------------------------------------------


On May 17, 2015, 5:47 p.m., Raphael Kubo da Costa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123832/
> -----------------------------------------------------------
> 
> (Updated May 17, 2015, 5:47 p.m.)
> 
> 
> Review request for KDE Utils and Raphael Kubo da Costa.
> 
> 
> Bugs: 335411
>     http://bugs.kde.org/show_bug.cgi?id=335411
> 
> 
> Repository: ark
> 
> 
> Description
> -------
> 
> Errors while extracting an archive entry in copyFiles() were being
> discarded without informing the user, who would then believe the entire
> extraction had worked correctly. We now emit the error() signal when
> there is an error and cancel the extraction.
> 
> Other callers of archive_write_header() have also been modified to use
> the same coding style (handling errors in a switch()) and error message
> format for consistency and ease of future maintenance.
> 
> Additionally, none of the error messages use archive_error_string()
> anymore. While this means the messages are less detailed, it also means
> users who use a translated KDE will not see part of the error messages
> hardcoded in English.
> 
> 
> Diffs
> -----
> 
>   plugins/libarchive/libarchivehandler.cpp 75cf759d5e67508288ee6a42d42b4c0d6b557afe 
> 
> Diff: https://git.reviewboard.kde.org/r/123832/diff/
> 
> 
> Testing
> -------
> 
> Creating archives still works as before, and error messages during extraction (such as the one in bug 335411) are properly reported.
> 
> 
> Thanks,
> 
> Raphael Kubo da Costa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-utils-devel/attachments/20150522/53642870/attachment.html>