Write JOSS paper draft for repository #1
Closed
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
Add complete Journal of Open Source Software (JOSS) submission package: - paper.md: Complete JOSS paper with all required sections - Summary of ObjectState framework and dual-axis inheritance - Statement of need for scientific computing workflows - Comprehensive state of the field analysis - Implementation details and quality assurance metrics - Working code example demonstrating key features - Research applications and future directions - paper.bib: Complete bibliography with 28 citations - Software engineering best practices - Existing configuration frameworks - Python Enhancement Proposals - Design patterns and revision control systems - JOSS_SUBMISSION_NOTES.md: Submission guidance - Pre-submission checklist - Author ORCID update instructions - Repository requirements verification - Review process overview The paper rigorously documents ObjectState's novel dual-axis inheritance model (context hierarchy + class inheritance), integrated state management with git-like undo/redo, and zero-dependency pure-stdlib implementation. Ready for author review and ORCID update before submission.
Add transparent disclosure of AI assistance in paper drafting per JOSS requirements. Clarifies that all technical content and software implementation are original human intellectual work.
Update paper to reflect that ObjectState was developed within the OpenHCS monorepo over an extended period before being extracted as a standalone package. This context explains the software's maturity, production use, and comprehensive test coverage, and situates it within the ongoing decomposition of the OpenHCS monorepo into modular, reusable components.
trissim
added a commit
that referenced
this pull request
Jan 13, 2026
…all behavior This commit fixes three critical bugs in the parameter form manager related to nested configuration dataclasses, completing the context tree refactoring work. **Problem 1: Nested Config Edits Not Reflected in Sibling Placeholders** When editing nested config fields (e.g., well_filter_config.well_filter), the changes were visible in the nested manager but sibling configs (path_planning_config, step_well_filter_config, etc.) were not seeing the updated values in their placeholders. They continued to show 'Pipeline default' instead of inheriting the newly edited value. Root Cause: - Nested manager updated its own self.parameters correctly - Parent manager received the parameter_changed signal - But parent's self.parameters[parent_field_name] was NOT being updated - When siblings built their context stack via ConfigNode.get_live_instance(), they got the parent's stale nested dataclass values - Additionally, nested managers were registering as isolated root nodes in the tree registry instead of as children of the parent node Fixes: 1. Update parent's self.parameters[parent_field_name] when nested fields change (parameter_form_manager.py:1074) 2. Add parent_field_name to parent's _user_set_fields for save persistence (parameter_form_manager.py:1079) 3. Pass parent_node=self._config_node when creating nested managers so they register as children in the tree registry, not isolated roots (parameter_form_manager.py:622) **Problem 2: Nested Config Edits Not Saved to Disk** When editing nested config fields in PipelineConfig and saving, the changes were lost. On reopen, the fields reverted to their original values. This worked fine for GlobalPipelineConfig and StepConfig, but not PipelineConfig. Root Cause: - When nested fields changed, parent's self.parameters was updated (fix #1) - But parent's _user_set_fields was NOT updated - get_user_modified_values() only returns fields in _user_set_fields - So when saving, the modified nested configs were excluded from the save - Result: nested config changes were discarded Fix: - Add parent_field_name to self._user_set_fields in _on_nested_parameter_changed (parameter_form_manager.py:1079) **Problem 3: Reset All Button Doesn't Trigger Sibling Placeholder Updates** Clicking 'Reset All' on a nested config (e.g., well_filter_config) reset the fields correctly, but sibling configs didn't update their placeholders. Individual field resets and manual edits worked fine, only 'Reset All' was broken. Root Cause: - reset_all_parameters sets _block_cross_window_updates=True for performance - _on_nested_parameter_changed checks _should_skip_updates() which returns True when _block_cross_window_updates=True - This blocked not only cross-window signals (intended) but also local parent parameter updates and sibling placeholder refreshes (unintended bug) - The flag was being used too broadly Fix: - Change _on_nested_parameter_changed to only check _in_reset flag, not the full _should_skip_updates() check (parameter_form_manager.py:1033) - This allows local updates (parent parameters, sibling placeholders) while still preventing cross-window signal spam during bulk operations **Problem 4: Cleared Fields (None) Re-materialize on Save/Reopen** When clearing a field (setting to None), saving, and reopening, the None value would be materialized back to a concrete value. User explicitly cleared the field but it came back. Root Cause: - get_user_modified_values() correctly returned None for cleared fields - But reconstruct_nested_dataclasses() called the lazy dataclass constructor with None values: LazyWellFilterConfig(well_filter=None) - The constructor's __post_init__ method resolved the None against context, materializing a concrete value instead of preserving the None - This defeated the purpose of clearing the field Fix: - Separate None and non-None values in reconstruct_nested_dataclasses() - Create instance with only non-None values (let lazy resolution work normally) - Use object.__setattr__ to set None values directly, bypassing lazy resolution (dataclass_reconstruction_utils.py:47-77) **Architecture Context** These fixes complete the context tree refactoring described in plans/ui-anti-ducktyping/plan_01_context_tree.md. The tree registry provides hierarchical context resolution (Global→Plate→Step) with proper parent-child relationships for nested configs. Key insight: Nested configs are NOT separate tree nodes - they're part of the parent dataclass. But they have their own form managers for UI editing. The parent must track changes to nested fields and propagate them to siblings. Files Modified: - openhcs/pyqt_gui/widgets/shared/parameter_form_manager.py - openhcs/pyqt_gui/widgets/shared/services/dataclass_reconstruction_utils.py - openhcs/pyqt_gui/widgets/shared/services/placeholder_refresh_service.py
trissim
added a commit
that referenced
this pull request
Jan 13, 2026
…8ajCrKAaiXCGhTmN63 Set up tests, docs, and CI pipeline
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.