Skip to content

Fixes to GUI Settings and general workflow#1840

Open
Seneral wants to merge 5 commits intoSlimeVR:mainfrom
Seneral:general-fixes
Open

Fixes to GUI Settings and general workflow#1840
Seneral wants to merge 5 commits intoSlimeVR:mainfrom
Seneral:general-fixes

Conversation

@Seneral
Copy link
Copy Markdown

@Seneral Seneral commented May 8, 2026

These fixes were made while working on improving VMC support, as the OSC-related settings pages, especially VMC itself, were very unreliable prior to this.
The first commit is a bonus workflow improvement (confirmed a problem on Linux when server is run from the command line).

This requires SlimeVR/SolarXR-Protocol#212

Seneral added 5 commits May 8, 2026 20:07
Affects use in command line on linux (gradlew run) when interrupted with Ctrl + C
Does not seem to affect use through IntelliJ Idea Services
Clearing a selected file would navigate to "#" and thus return to the home page
This was observed with the VRM model in the VMC settings
Server may send SettingsResponse which are not fully populated
E.g. only "steamVrTrackers" is set, with others null
These three settings pages would reset to default values whenever this occured
vrmJson setting is managed by a separate VMCFile component
But it used the same change request as the rest of the settings managed by the main component
So VMCFile component kept a copy of the VMC settings state, updated from SettingsResponses
It then copied the other VMC settings manually to keep them (!)
Conversely, the main component just didn't update the vrmJson
There were two problems with this:
- A possible race condition as VMCFile may overwrite past changes (rarely a problem in practice)
- Manual copying of settings left out newer boolean flags
This meant some settings were reset when changing vrmJson
- Only reflected in GUI by leaving the settings and going back to them

The best solution is to separate the change requests outright:
- prevent race condition entirely, even edge cases
- does not require changes to both change requests when new settings are added
But to keep the server-side similar, the underlying config has not been split
This is rather unorthodox, but splitting those up further - but keeping both on the same settings page - is also confusing
@github-actions github-actions Bot added Area: Application Protocol Related to communication with apps like the GUI, overlay, games Area: GUI Related to the GUI Area: Server Related to the server labels May 8, 2026
@Seneral Seneral marked this pull request as ready for review May 8, 2026 18:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: Application Protocol Related to communication with apps like the GUI, overlay, games Area: GUI Related to the GUI Area: Server Related to the server

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant