Properties tab for checksum

[zhanghai]

[ndnddkoeo3dkej9]

For example you add CRC-32, MD5, SHA-1, SHA-256.

But when the checksum tab is opened, not everything should be hashed immediately automatically, because with larger files it can take a long time and consumes resources.

But have the possibility to decide yourself when the files are hashed and which procedure (click on all or the individual).

[iTrooz]

Are you currently working on this ? I'd like to give it a try

EDIT : Didn't there was a PR open for this, I'm going to check it EDIT 2 : Still not sure if you're working on this or not, or if you need help. If you want to talk about implementation details, we could talk here or on discord : iTrooz_#2050 (I'm new in Android development, but often, just talking can help to find the solution)

[zhanghai]

It's more of a design problem than implementation, e.g. when we start the computation or whether we allow the user to trigger it manually/again. And how we show/handle different types of checksums (showing all types of checksums at once save the number of disk reads, but that's more CPU time. The alternative is to have a dropdown so that we compute one type at a time). Also if we want to allow the user to do comparison, how we design a UI that accommodates doing that for different types of checksums while not being too verbose and fits into the existing app design.

You may take a look at the pull request template for the reason I'm not accepting code contributions for this project for now, but I'm happy to discuss the design here and I can implement when I have time.

[iTrooz]

Personally, I think Dolphin (the KDE file manager) got a pretty good design : A button per hash type, and we click on the button it disappears to show the hash. I don't think most users will want to compute several hashes per file, so the main use-case should be preferred

For the comparison, we could once again do the same as Dolphin : a text field to enter the hash, and the app detects the hash type based on the length, and computes/compares it

We could even reduce that to a "compare with clipboard" button, that takes the current clipboard, detect the hash type based on the length, etc...

I'm not sure if that would go with the general design of the app. What do you think ?

[zhanghai]

GtkHash's Nautilus plugin shows a table of different types of hashes and has one field to check any of the hashes, and computes all hashes at once upon one button click.

AmazeFileManager shows MD5 and SHA256 in its file properties dialog and starts the computation immediately upon opening the dialog.

Solid Explorer shows MD5, SHA1 and SHA256 in its Checksum tab in file properties page. Each type of checksum has a dedicated button that only starts the computation upon click.

MiXplorer shows CRC32, MD5, SHA1, SHA256, SHA384, SHA512 in the checksum dialog and starts the computation immediately upon opening the dialog.

The UX is indeed a bit divided. The argument for calculating all hash at once may be that the hash functions are actually fast and it's mostly the disk reads, or even network reads, are slow, so that we should always compute all hashes at once.

[iTrooz]

I think I get the problem.. To be honest, I think that, all things considered, both are "good" solutions. I mean, both works, and we shouldn't aim for the best implementation but for an implementation that solves most use cases

I personally prefer clicking a button to manually compute the hash, but if computing all the hashes at automatically works for people use-cases (and if so many file managers do that, I think it works), doing it is a also good choice

And if some people have issues with it with large files, and ask for a fix, we could always add a Dolphin-like button to compute hashes manually for large files. But later, only if people ask for it

On a personal note, I have issues with overthinking, and I think that this here is a case of overthinking.

I think the worst would be not to implement anything because you can't choose between two implementations. It's what I sometimes do, and I always realize that it's the only bad choice I can make. Not choosing between two good solutions because "idk what is better"

Not trying to pressure you into doing it if you simply don't have time, btw

[mosource21]

This would be fantastic addition. I hope https://github.com/zhanghai/MaterialFiles/pull/303 qualifies for merging soon. After recently migrating to open source apps and choosing Material Files for my file manager this is really the only the feature I miss.