Generic dialog

[GoogleCodeExporter]

Seeing as XOR, Vigenere and Caesar all use pretty much the same dialog, I was 
wondering if we should make a "generic dialog" (containg just intput, output 
and key edit). The only problem I see would be the key validation.
Just tell me what you think :)

Original issue reported on code.google.com by xander.deseyn on 25 Jan 2012 at 7:01

[GoogleCodeExporter]

So you're saying we should derive a class from EncryptDialog, named 
EncryptGenericDialog.
In that class we add the key field (which is in fact the only difference with 
EncryptDialog).
We can use a pure virtual function that validates the key, and reimplement that 
function in every child class.

I find this a good idea, because we will certainly add more algorithms using 
this kind of dialog in the future. Therefore I've changed the priority to 
medium.

Original comment by Divendo1180@gmail.com on 25 Jan 2012 at 9:01

• Added labels: Component-Logic, Maintainability, Milestone-Release1.0, Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Come to think about it, we don't even need to make that class. We just include 
in encryptdialog, because after all, every encryption will need a key right? 
What troubles me is that we have so much boilerplate code in the constructors 
of its derivatives...

Original comment by xander.deseyn on 25 Jan 2012 at 9:34

[GoogleCodeExporter]

Not every algorithm needs the same type of key.
RSA for example requires two integers, while Vigenère (as we know) requires a 
password.
So the key validation function can go in EncryptionDialog.
The creation of the key input field should go in a child (e.g. 
EncryptGenericDialog).

By the way, not every encryption algorithm requires a key.
We may want to implement hash algorithms (MD5, SHA1, etc) in the future, these 
don't require a key.

Original comment by Divendo1180@gmail.com on 25 Jan 2012 at 9:57

[GoogleCodeExporter]

Solution: the EncryptDialog class and the EncryptionAlgorithm class should be 
merged.
This way each algorithm will be implemented in one class, which includes the 
dialog for the algorithm and the algorithm itself.
For algorithms that are a lot like each other (e.g. XOR and Vigenère) we can 
create another abstract class first from which these algorithms will derive.

Original comment by Divendo1180@gmail.com on 12 Feb 2013 at 4:31

[GoogleCodeExporter]

Fixed in r22

Original comment by Divendo1180@gmail.com on 12 Feb 2013 at 6:46

• Changed state: Fixed