Collision

Collision copied to clipboard

Describe the request

Hello. I suppose there is potential to cover advanced options:

note: a relevant suggestion of an addition of an option to disabling/enabling algorithms exits, so I won't duplicate that suggestion.

Suggestions:

• Along with the existing support of the source which is illustrated by a single file, it would be advantageous to have supports for these sources: multiples files and single text string.
• Bringing those supports would require in interface the presence of a new option –e.g. Source or View– in order to select the view accordingly to the source; File, Multiple files and Text.
  • Common to each view | ability to compute hashes
  • Common to File and Text views | presence of a field in which to insert a check sum

Implementation Details

• [X] This follows the GNOME HIG.

Thanks for all the suggestions!

Personally, I'm in favor of having a very simple UI for this app. I want people who don't know how to use a terminal or what hashing is to bother verifying their files' hashes. Having a complicated UI with many concepts such as "sources" and "views" might overwhelm them and give up.

The current approach to multiple files is to open a new window for each one (which you can also do automatically by providing a list of files to the app).

I don't mind text as input but it does feel out of scope of the app

Advanced users are more likely to use the CLI anyway or Text Pieces for text related operations

Minimalistic in respect to capabilities might reveal to be a wise decision. Thanks to knowing your opinion in regard to the positioning you want for your application to have, I won't make the suggestion that I had planned to submit to you, which was to add support for HMAC functions. As for text as source, which I considered an advanced option; you are coherent to consider it as out of scope, knowing this software positioning.

As it can be deducted from the existence of the New window option, support for multiple instances exists. As it appears though, at best, there is no more than one option to operate a file selection, and as I can observe it is a single file per instance. As a consequence I am unable to interpret what you meant to express by providing a list of files to the application. since there is no such option provided to achieve what the sentence describes.

Nothing is set in stone of course! That's just my current position which might change in the future

I'll see about HMAC as I'll have to deal with bindings. FWIW, #174 already adds 3 more hash functions (Blake3, CRC32, Adler32).

there is no more than one option to operate a file selection

That's true and I consider it a bug, I'll open an issue to track it, thanks for pointing it out!

As a consequence I am unable to interpret what you meant to express by providing a list of files to the application. since there is no such option provided to achieve what the sentence describes.

There's at least 2 ways to do it:

1. using the CLI to pass multiple files to Collision collision ./file1 ./file2 ./file3
2. using the nautilus-extension (the README has instructions), selecting multiple files in nautilius and right clicking > Check Hashes

But selecting multiple files in the filechooser is more appropriate!

By HMAC functions I am referring to keyed hashing –HMAC algorithm hash derived from a HMAC key. For illustration, here are some representatives: HMAC-SHA3-384, HMAC-SHA256, HMAC-RIPEMD160, HMAC-MD5.

I was not aware of these two relevant ways you presented for operating a multiple files selection, as I thought this application is solely as GUI. Such a selection within the application GUI could be a common primary reaction, who knows. At least that how it is for me.

Would it be be a relevant suggestion to you, to provide these three options of digest format –hexadecimal upper and lower cases and Base64? The program's current state provides one option –hexadecimal lower case; that may not meet the requirement set by the user.