Guard module-scope addCommand() calls with FreeCAD.GuiUp - #325
Merged
Conversation
The import FreeCADGui line above each of these is already guarded this way, but the addCommand() call itself was not, so importing any of these 15 modules without a GUI (e.g. via freecadcmd, or any headless script/test) raises NameError. CfdOpenPreferencesPage.py is intentionally left as-is: it imports FreeCADGui unconditionally and is a GUI-only command.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
FreeCADGui.addCommand()is called unguarded at module scope in 15 files, even though theimport FreeCADGuiimmediately above each call is already guarded withif FreeCAD.GuiUp:. Importing any of these modules without a GUI present (e.g. viafreecadcmd, or any headless script/test harness) raisesNameError: name 'FreeCADGui' is not defined.This makes it impossible to script or test the workbench headlessly — every CfdOF module that registers a command hits this.
Fix
Wrap each addCommand() call (or contiguous run of them) in the same
if FreeCAD.GuiUp:guard already used for the import above it. GUI behaviour is unchanged:Init.pyonly registers a lazy import type, and the affected modules are imported insideCfdOFWorkbench.Initialize(), which runs afterFreeCAD.GuiUpis set — so the guard only takes effect in the headless case, where the commands couldn't have registered anyway.CfdOpenPreferencesPage.pyis intentionally left alone: it importsFreeCADGuiunconditionally at module scope and is a GUI-only command, so there's no headless code path to protect.Testing
Verified by importing the affected modules and running
checkCfdDependencies()underfreecadcmd— all import cleanly and the dependency check completes without error. Not run through the fullFreeCAD -t TestCfdOFGUI-based suite (no GUI-visible behaviour is touched, so no regression expected there, but flagging for visibility).