-
Notifications
You must be signed in to change notification settings - Fork 57
docs: Update ui_mode doc [skip tests] #4533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Updates the docstring for the ui_mode parameter across multiple Fluent launcher files to use consistent terminology and remove the optional designation in one location.
- Standardizes the
ui_modeparameter description to use "Defines the user interface mode for Fluent. Options correspond to values in the UIMode enum." - Removes the detailed explanation of specific UI mode values and version requirements from the main launcher
- Corrects the parameter type from optional to required in
session_utilities.py
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/ansys/fluent/core/session_utilities.py | Removes "optional" designation from ui_mode parameter type |
| src/ansys/fluent/core/launcher/slurm_launcher.py | Updates ui_mode description to use standardized language |
| src/ansys/fluent/core/launcher/launcher.py | Simplifies ui_mode documentation by removing detailed options and version info |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.
…yfluent into docs/update_ui_mode_docs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
closes #3886
Context
Prior to this change, the ui_mode parameter in several parts of the PyFluent codebase had an incomplete or slightly misleading docstring. Users could pass either members of the UIMode enum or specific string literals (e.g. "no_gui", "hidden_gui", etc.), but that flexibility was not well documented. This ambiguity could lead to confusion about which string names are valid and how they map to enum values.
Change Summary
Updated the docstrings in launcher.py, slurm_launcher.py, and session_utilities.py to better describe accepted ui_mode values (both enum and string forms).
Clarified which string names correspond to which UIMode values (e.g. "no_gui_or_graphics", "no_gui", "hidden_gui", "gui", etc.).
Removed or refined outdated or redundant lines in the existing doc comments.
Ensured consistency across the codebase about how ui_mode is explained.
Marked the PR to skip tests, since only docstrings were changed.
Rationale
Better user experience / usability: Clear documentation helps users (and maintainers) know exactly what ui_mode values are supported.
Reduce confusion / errors: Users may try unsupported strings or misuse the enum; this aims to guide them.
Maintain consistency: Before, docstrings in different modules had slight variations or omissions. This change harmonizes those descriptions.
Low risk: Since only documentation is modified (no logic changes), this is a safe improvement.
Impact
Documentation / developer experience: Anyone reading or using code involving ui_mode will get more precise information on acceptable values.
Minimal to no runtime impact: Because no functional logic was changed, existing behavior remains unchanged.
Future maintenance: When extending or deprecating a ui_mode, future contributors can rely on the docstrings being consistent across modules.
Testing: No tests should break (and the PR is marked [skip tests]), but doc validation tools (if present) may pick up formatting or lint changes.