Allow user to set alignment parameters in GUI

[mvences]

Because changing the scores.tab file is not possible in the compiled standalone tools, the way the program sets these values should be changed and the user should be given the option to change each of these in the GUI. This is not a priority issue and can be tackled later when overhauling the GUI.

[necrosovereign]

I've had an idea for an alternative way to handle this. I've learned that both Windows and Unix have standards that designate special folders that programs can use to store data (Special folder (Windows), Base directory specification (Unix)). We can use this directories to store the alignment parameters and direct the users to them in the manual.

[mvences]

Hmm, I am not really convinced of this solution. The main point is to give users the option to modify easily from the GUI the parameters, and if necessary, rerun analyses with different alignment parameters.

Maybe we can somehow work with a temporary file? If nothing is changed by the user, the program will work with default parameters as specified in the configuration file, as it is done now. If the user in the GUI chooses to modify parameters, the program writes a new configuration file to a temporary folder from where then the alignment routines take the necessary information. Would this work?

[StefanPatman]

The Gui will easily be able to provide the scores_dict dictionary via an API function call. There is no need to read it from a file.

[necrosovereign]

I think there needs to be a user-editable file, so that the alignment parameters can persist between when the program is not running and so that they can be fine-tuned for the user's use-case.

[mvences]

I am not sure if I understand everything cpmpletely. But what I can say is for the final compiled version, I don't think it is necessary that the user changes will be stored from one run of the program to the next. If the user closes the executable, it is OK if all settings get lost, and when the executable starts anew, it does so with the default settings.

[StefanPatman]

I planned to address this in an email later, but I think this is a good opportunity for discussion. Here is a very simple frontend/backend architecture:

Scores.tab is part of the input, along with the input files and the user options. The core module (=backend) should not worry about how this information is provided. It should simply expose an API function that accepts the input and provides the output.

For instance: def all_aganst_all_comparison(input: Path, scores: Dict[str, int]) -> Path:

The core module should not care how the dictionary is provided: even though it could indeed be saved in a file somewhere! If this were a console application, you could imagine a call like this: taxi3-all --scores=scores.tab input.tab. The program does not care where the scores file is saved, only that it is provided by the user (and using default values otherwise).

There are many good sources out there about why this approach is a good idea. In our case especially, since we are a remote team and collaboration on the same code-base is "slow and awkward" (see our experience with Concatenator).

The same concept can apply to more complicated scenarios (logging, progress bars) by using classes.

[mvences]

Of course I cannot fully overlook the direct consequences of this architecture, but to me it looks very clean and straightforward to implement.

Maybe we can keep a version of the program (or an option for the program) which runs without the new GUI and in this case the backend fetches the scores.tab file from a dedicated folder, as it is doing now.

But when the program is run from the new GUI, indeed it would be best if the scores.tab information was provided from the GUI to the backend.