Fix type saving of Parameter sublcalsses with saveState() / restoreState() (issue #3430) #3431
+116
−13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
December 1, 2025 14:34
fix parameter example in parametertree add a type checking in the Parameter init function
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Resolves #3430
This PR fixes the issue where custom
Parametersubclasses (e.g.ComplexParameterandScalableGroup, defined in examples/parametertree.py) cannot be correctly restored usingsaveState()andrestoreState().The cause of this problem is that these classes overwrite
opts['type']with existing types (e.g. 'group') already associated to an otherParametersubclass.Thus, for example, the restore mechanism instantiates a
GroupParameterinstead of the expected subclassScalableGroup. Similarly, it instantiates aSimpleParameterinstead of aComplexParameter.Summary of changes
1. Use and register unique parameters types
We use unique type names ('complexparameter', 'scalablegroup') for the example subclasses
ComplexParameterandScalableGroupand register them usingregisterParameterType().2. Add a type check in
ParameterCreated a new method
check_type(). It validates that:PARAM_TYPESThis method is then called in the
__init__function ofParameter.3. Add a
compare_parameters()functionCreated a new function
compare_parameters()that allows to compare two parameters. In particular, it checks that the parameters classes are the same.The existing
eq()function only compare saved states and cannot compare classes.4. Add tests
compareParameters()5. Fix
BoolOrRadioParameterinconsistencyA
BoolOrRadioParametercould represent a 'bool' or a 'radio', but only one class per type can be registered inPARAM_TYPES. Thus, it caused inconsistencies. To resolve this:BoolOrRadioParameterclass.RadioParameter, associated to the 'radio' type;ChecklistParameterso the created list items are either aBoolParameteror aRadioParameter.Conclusion
Parametersubclasses are now properly saved and restored.