Added explicit toggles for FrameTime Lock Method, Restored both Added color correction settings (PR #490) and Added remove presets feature (PR #496) #640
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.
Improved the Web GUI in the FrameTime Lock section by adding explicit toggles for each method
Improved the Web GUI in the FrameTime Lock section by replacing the single "Switch Lock Method" cycling button with explicit toggles for each method. This change makes it immediately clear which FrameTime Lock method is active, improving usability and removing the need to consult logs.
Before:
The active method was hidden; switching required pressing the arrow button and observing the effect.
After:
Each method now has its own toggle button. The currently selected method is highlighted, allowing faster and more intuitive control.
Restored 'Added color correction settings' (PR #490) and 'Added remove presets feature' (PR #496)
This was an issue when building off the current source as the contributor edited the generated webui.html directly instead of index.html.tpl. Changes were lost on build when running 'npm run build'.
Issue - 'Added remove presets feature' (PR #496)
I noticed some instability when removing presets. The Wi-Fi connection tends to drop pretty easily when cycling through different presets to delete. I haven’t tested this on other GBS-C units yet, so not sure if it’s specific to this unit.
There were two cases where deleting a preset caused a soft brick that wouldn't allow the Web GUI to load on reboot. I haven’t been able to reproduce this reliably, though.
For now, I’m just adding back the previously approved pull. I haven’t reviewed the code in depth yet to see what fail safes are in place or whether it tries to switch to a protected/default preset before the delete to avoid leaving the active one as the deleted one. My guess is that maybe the active preset got removed mid-process, and on reboot the system couldn’t find it.
Feedback
Noticed something while testing on mobile that when scrolling down, any buttons using gbs-click="repeat" can still register input unintentionally. It seems like a scroll that passes over those buttons might trigger them, even without a deliberate tap. Noticeable when I was adding back 'Added color correction settings' on a smaller display.
Not sure if there's a clean way to prevent that, maybe by ignoring touchstart events unless it's a clear tap/hold rather than part of a scroll. Just flagging it in case it’s worth looking into a safeguard or input debounce.