The preset name in the module header may not reset when the module settings are reset

[victoryforce]

When I select a preset for a module and then go back to the previous values by pressing Ctrl+z for Undo, I expect the preset name to be removed from the module header, because now the module settings do not match the given preset.

It does work with the following sequence of actions:

• toggle on the module
• select a preset
• press Ctrl-Z to undo

Bit it doesn't work with the following sequence:

• select a preset without first toggling on the module
• press Ctrl-Z to undo

As a result, the module settings and the name of the preset can be desynchronized.

Reproducible in the current git snapshot at the time of raising the issue (4.5.0+1402~g9f0088ce53).

[TurboGit]

Indeed, and expected as in the second case the module is not activated so there is no history recorded. Since Ctrl+Z works on history, as I said expected.

I'm not saying we cannot do better, at least one option would be to activate the module when changing the name. But this may have other consequences.

[victoryforce]

Indeed, and expected as in the second case the module is not activated so there is no history recorded. Since Ctrl+Z works on history, as I said expected.

Expected for the developer, yes, but very unexpected behavior for the user. And it is reasonably considered by users as a bug

I have never used undo (and redo), my established workflow habits are direct selection of steps in history. But the user whose complaint I am proxy-forwarding has exactly this habit. And to be honest, a keyboard shortcut for the left hand is indeed more convenient than traveling the mouse to the other side of the screen to select a previous point in the history. He complains that this shortcoming is driving him crazy.

I'm not saying we cannot do better, at least one option would be to activate the module when changing the name. But this may have other consequences.

When I select a preset from the menu, this action not only changes the settings of the module, but also activates it. Likewise, the module is enabled when a new instance is created and when the additional name is changed. That is, the module is also activated in the current implementation.

Maybe the problem is in the wrong order and we just need to activate the module earlier in the code? I'm just speculating, I've never looked at this code...

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.