Sub-issue of #138.
Many numeric fields in the input-parameters form are implemented as pn.widgets.LiteralInput(type=int, ...). When a user types a non-numeric value (e.g. "blah some text"), Panel silently reverts the field to the last valid value. This is visually confusing — users can't tell whether their input was accepted, and there's no feedback explaining why it was rejected.
The z-score baseline fields (baseline_wd_strt, baseline_wd_end) are one example, addressed in #283 by switching to pn.widgets.IntInput, which rejects non-numeric input at the browser level (native <input type="number">).
The same treatment should be applied to the other LiteralInput(type=int) widgets in src/guppy/frontend/input_parameters.py so the form behaves consistently:
timeForLightsTurnOn
numberOfCores
moving_wd
highAmpFilt
transientsThresh
moving_avg_filter
no_channels_np
nSecPrev, nSecPost
timeInterval
bin_psth_trials
baselineCorrectionStart, baselineCorrectionEnd
Sub-issue of #138.
Many numeric fields in the input-parameters form are implemented as
pn.widgets.LiteralInput(type=int, ...). When a user types a non-numeric value (e.g."blah some text"), Panel silently reverts the field to the last valid value. This is visually confusing — users can't tell whether their input was accepted, and there's no feedback explaining why it was rejected.The z-score baseline fields (
baseline_wd_strt,baseline_wd_end) are one example, addressed in #283 by switching topn.widgets.IntInput, which rejects non-numeric input at the browser level (native<input type="number">).The same treatment should be applied to the other
LiteralInput(type=int)widgets in src/guppy/frontend/input_parameters.py so the form behaves consistently:timeForLightsTurnOnnumberOfCoresmoving_wdhighAmpFilttransientsThreshmoving_avg_filterno_channels_npnSecPrev,nSecPosttimeIntervalbin_psth_trialsbaselineCorrectionStart,baselineCorrectionEnd