Review Request 128283: Add checksums tab to the properties dialog

Sat Jun 25 13:02:12 UTC 2016

> On June 25, 2016, 12:52 p.m., Thomas Pfeiffer wrote:
> > First of all: I love the feature as such, as it makes the whole checksum comparison story actually usable for average users (although they'd still have to be told how to do it because they'd probably not get the idea that they'd find it in the properties dialog)!
> > 
> > I agree with Christoph and David that it shouldn't just calculate all three checksums as soon as one clicks on the tab.
> > 
> > Let's talk through typical user stories:
> > 
> > I assume the most common story is a user downloading a file from a website which provides a checksum (either on the site or in the form a text file), and then wanting to check file integrity using that sum.
> > 
> > For that, the user does not need all three sums (even if all three are provided, there is little use in checking _all_ of them, is there?).
> > From an average user's perspective, the ideal situation would be that they's simply have to paste the checksum they have into a generic checksum field, then it would be automatically detect which type of checksum it is, the corresponding checksum would be calculated and the comparison would be made. Would that be possible?
> > 
> > We have to be aware that the whole checksum business is pretty advanced and difficult to understand for most users, which is why I fear that it is far less often used than it should be. Therefore, the less knowledge about checksums a user needs in order to complete the task, the better.
> > 
> > 
> > Another story would be a user wanting to share the actual checksum somewhere. For that, they'd need a way to generate it manually. Even then, however, how likely is it they'd need all three?
> > For this story I'd provide either three different "Calculate Checksum" buttons or one drop down button to select which one to calculate, and then calculate only that.

Thanks for the feedback!

> I agree with Christoph and David that it shouldn't just calculate all three checksums as soon as one clicks on the tab.

Got it, indeed it's not that useful to show all 3 of them at the same time.

> From an average user's perspective, the ideal situation would be that they's simply have to paste the checksum they have into a generic checksum field, then it would be automatically detect which type of checksum it is, the corresponding checksum would be calculated and the comparison would be made. Would that be possible?

I think it should be possible. We could check the length of the pasted checksum and guess the type of algorithm from that.

> Another story would be a user wanting to share the actual checksum somewhere. For that, they'd need a way to generate it manually. Even then, however, how likely is it they'd need all three?
For this story I'd provide either three different "Calculate Checksum" buttons or one drop down button to select which one to calculate, and then calculate only that.

Makes sense as well. Using a dropdown button should be the simplest possible solution.

- Elvis

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

On June 25, 2016, 10:39 a.m., Elvis Angelaccio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128283/
> -----------------------------------------------------------
> 
> (Updated June 25, 2016, 10:39 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> This patch adds a Checksums tab in the properties dialog, where the user can retrieve and verify the most popular checksum algorithms (md5, sha1 and sha256). 
> 
> To simplify the implementation, the checksums are computed as soon as the user opens the dialog. This can take a while if the file is huge (in particular with sha256), but the computation happens in another thread and in practice this should not be a performance problem.
> 
> The tab is available only for readable local files (no simlinks) and only when there is a single selection.
> 
> Please note that some of the labels in the screenshots are clipped due to a bug in breeze: https://bugs.kde.org/show_bug.cgi?id=364426
> 
> 
> Diffs
> -----
> 
>   src/widgets/CMakeLists.txt f9065777a0d2f1d126dc482d66e1bbb1ba127895 
>   src/widgets/checksumswidget.ui PRE-CREATION 
>   src/widgets/kpropertiesdialog.cpp d0a2faa5114e391680925e10646ce7c6f2ea29da 
>   src/widgets/kpropertiesdialog_p.h c01554e694ff3c905e768048ce94800739760fb7 
> 
> Diff: https://git.reviewboard.kde.org/r/128283/diff/
> 
> 
> Testing
> -------
> 
> * Check whether the computed values match the values from md5sum, sha1sum, sha256sum.
> * Check whether the line edits get a green background if the computed and expected values match.
> * Check whether the line edits get a red background if the computed and expected values differ.
> 
> 
> File Attachments
> ----------------
> 
> sha256-computing
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/06/25/327218af-c026-458e-a48d-512787abad42__Spectacle.st2415.png
> md5-match
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/06/25/4b37d28e-02b9-42e2-96f2-184ffd42b31a__Spectacle.kh2415.png
> sha1-differ
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/06/25/99fdcf92-f784-4a7d-8aba-c25b8be08c04__Spectacle.Xz2415.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160625/3ee32e30/attachment-0001.html>