When changing a setting in a container whose wine version has been uninstalled, the window hangs.

[qparis]

Expected behavior

Open a new SetupWizard

Actual behavior

The window is blocked until the wine version is installed

Steps to reproduce

• Create a prefix
• Remove the wine version manually
• Change a setting in the container panel (GDI for example)

[madoar]

Is it enough to call Engine#install(String subCategory, String version) in this case or does the container require some modification/adjustment too?

[qparis]

It is already the case. The problem is that there are no wizard

[plata]

If we implement the behavior you suggest, the following would happen:

1. The combobox to change the engine setting opens.
2. The user selects a combobox entry.
3. While the combobox selection is still open, the GUI suddenly opens the installations dialog and starts the installation of the required engine version.
4. The engine installation finishes, the user can go back to the containers tab.

I'm questioning that this behavior is understandable for anybody. It will most likely cause questions like "What did just happen?", "Why does this installation start now?" etc. This is a general issue not only for engine settings but for anything that's using an engine. Even worse, the behavior might be different depending on the engine type. Therefore, I propose to get rid of implicit engine installations completely (i.e. do not call install in Engine#run). Instead, throw an exception that the required engine is not available. Yes, it will mean that the user must trigger the engine installation manually but:

1. This will not happen unless you explicitly uninstall the engine before.
2. It is clear what's going on.

[plata]

Is this really relevant for alpha-3?

[madoar]

Is this really relevant for alpha-3?

I don't think so.

Therefore, I propose to get rid of implicit engine installations completely (i.e. do not call install in Engine#run). Instead, throw an exception that the required engine is not available.

I agree that this would be a better approach in general. But I think that it is not intuitive in case where you are executing an installer script. In this case I would expect the script to automatically download everything necessary.

[plata]

But I think that it is not intuitive in case where you are executing an installer script. In this case I would expect the script to automatically download everything necessary.

That's the current behavior.

[madoar]

I know. Can't we change the method to take a flag as an arguments that leads to a check whether the engine is already installed/downloaded?

[plata]

I don't think that's required. The engine setting can check if the engine is installed before doing anything else.

[madoar]

What do you mean by engine setting?

[plata]

For example, the GDI setting @qparis mentioned in the description.

[madoar]

So essentially you propose to add a check to the beginning of any kind of engine usage method (I include the change engine method here). Only if the check is fulfilled the operation is executed otherwise an error/exception is thrown. In addition you want to add an additional method that ensures that an engine is downloaded/installed.

Both methods can then be combined as required in multiple situations, correct?

[plata]

Yes.