xtb_step Phase E – File Drop Notes#
Two issues from your stdout review:
frequencies.pyhadfrom seamm_util.printing import FormattedText as __imported but never used. Removed.TkOptimizationandTkFrequencieswere stand-alone copies of the cookiecutter genericTkNodetemplate – so they did not inherit the dynamic solvent visibility fromTkEnergy, and future substeps (MD, …) would have to re-implement the energy layout from scratch. Refactored to the MOPAC pattern:TkOptimizationinherits fromTkEnergy,TkFrequenciesinherits fromTkOptimization. The energy frame and its conditional solvent layout are now defined exactly once.
Files in this drop#
Replace existing#
xtb_step/frequencies.pySingle-line change: removed the unused
from seamm_util.printing import FormattedText as __import. Otherwise identical to Phase D.xtb_step/tk_energy.pyRestructured to be the GUI base class. Modeled on
mopac_step/tk_energy.py. Key design points:create_dialogbuilds an explicit “energy frame” (ttk.LabelFrametitled “Hamiltonian Parameters”) and creates all energy widgets inside it. The dialog is no longer a flat grid inself["frame"].reset_dialoglays out the energy frame at row 0 and returns the next free row so subclasses can grid their own frames below it.reset_energy_framelays out the widgets inside the energy frame, with the conditional solvent visibility (hidden whensolvation model == "none", indented in column 1 when shown).
xtb_step/tk_optimization.pyNow
class TkOptimization(TkEnergy). Adds an “optimization frame” (ttk.LabelFrametitled “Optimization”) below the energy frame and creates only the optimization-specific widgets there (optimization level,max iterations,structure handling). The energy widgets and their dynamic behavior are inherited automatically fromTkEnergy.xtb_step/tk_frequencies.pyNow
class TkFrequencies(TkOptimization). Adds a “frequencies frame” titled “Frequencies / Thermochemistry” below the optimization frame, holding the frequency-specific widgets (optimize first,temperature,pressure).optimize firstis bound toreset_dialogso future iterations can hide the optimization frame when the user disables the initial optimization (v1 just re-lays out unconditionally).
Why the inheritance chain matches the parameter-class chain#
The non-GUI side already has:
EnergyParameters
<- OptimizationParameters
<- FrequenciesParameters
It is natural and minimal-code for the GUI to mirror that:
TkEnergy
<- TkOptimization
<- TkFrequencies
Each subclass walks ChildParameters.parameters and skips keys
already in any parent’s parameters (so widgets are not double-created),
which means adding a parameter to EnergyParameters automatically
puts it in the energy frame for all substeps with no further code
change. Adding a future MD substep with MDParameters(EnergyParameters)
gets the energy frame and its solvent dynamics for free.
Not in this drop#
xtb_step/optimization.py, xtb_step/xtb.py,
xtb_step/__init__.py, xtb_step/setup.py,
xtb_step/energy_parameters.py, xtb_step/substep.py,
xtb_step/metadata.py, xtb_step/energy.py,
xtb_step/optimization_parameters.py,
xtb_step/frequencies_parameters.py, the data files, and the
installer are all unchanged from your current working tree.
Code style#
All four files compile cleanly. All lines are <= 88 characters.
black --check not run here (no install access in this
environment), so a first make format may produce small
whitespace adjustments – those should be one pass and then stable.