Version 9 (modified by Matthäus Wander, 11 years ago) (diff)


Each plugin which is intended to be included in the CrypTool2 release setup, MUST fulfill the following requirements:

  • The plugin is running stable (no uncaught exceptions, no known defects, no ongoing development which changes the publicly visible behaviour)
  • A project sample is delivered and runs without errors
  • A XAML description is provided
  • All text strings shown to the user are internationalized, a German and an English localization is provided (please note: not yet fully supported by CT2 core components!)
  • The plugin has been tested succesfully

Additionally the following demands SHOULD be met. However they do not compose a necessary condition.

  • All plugin settings are changeable in play mode


The sample must be playable without entering any information. This means, the settings and input fields are predefined with some reasonable example values. A memo must be provided and must contain the following minimum information:

  • Short Introduction
    • In this part you should describe in general what can be seen in the sample, i.e. what it does.
  • Inputs
    • What are the inputs to this sample (e.g. plaintext, key etc.), which part should the user change to see a difference
    • Are there some restrictions on the input, e.g. only letters allowed or exactly 16 characters/bytes needed.
  • Execution
    • Explain in a step-by-step manner what actions are being executed in the sample
    • Which plugins are being used and if not intutively clear, why
    • Later when it will be possible to mark different areas with colors, also describe what in those areas is happening
  • Output/Result
    • What is the result of this sample
    • What should be noted/learned by this sample?

Please use the above suggestions as headlines in your memo field. This way a new user will find a consistent view when he opens a new sample. In case you need to integrate more information, which does not fin in any ob the above given sections, please add it at the end of the memo field.

Plugin Description

Each plugin must include a description. This description is intended as a general description of the plugin and (right now) done on XAML. In order to unify all plugin-descriptions, each description shall use the following structure:

  • Introduction
    • In this part you should describe in general which problem the plugin solves. If the problem itself is complex, it is a good idea to reference to a webpage here, which describes it in detail (e.g. wikipedia).
  • Settings
    • A plugin mostly supports several settings that often can't be grasped too easily by beginners. These settings and their purpose should be described in detail here.
  • Function
    • The functionality of the plugin (i.e. how it behaves and what it's results are) should be listed here. Of course, this shouldn't be a technical description of the implementation, but it should give the user all informations he must know to use it properly.
  • Relations to other plugins
    • Most plugins can only be used by combining them with other plugins, i.e. there functionality is only reachable or meaningful if there is a connection between this plugin and others. For instance, a lot of plugins require some kind of number input. So they have to be combined with the "Number Input" plugin. All of these relations to other plugins can be listed and described in this section to give the user a hint how he can make use of this plugin on his workspace.
  • Samples
    • Most plugins have their own samples in the "project samples" directory to demonstrate their use. These samples should be listed here, together with a short description.

Take a look at trunk/Documentation/Developer/XamlDescription/SampleDescription.xaml for a sample description.


Each plugin must provide at least one unit test. The minimum requirement for this test case is the following: for a given input/output pair the plugin algorithm shall be fed with the input values and the output values shall be checked whether they have been calculated correctly. The source of the input/output values shall be provided as text comment.

More sophisticated tests (multiple test cases, exhaustive data input, high coverage tests, gui tests) are nice-to-have, but not mandatory.

The test case shall use the same mechanism as the other existing test cases (see project DevTestMethods).