Add SteamVR offline launch feature

[Iemand005]

Added a toggle to choose to directly start SteamVR instead of using the steam protocol.

Benefits:

• Much faster startup and restart times
• Works offline
• No memory wasted by Steam
• Enables launching SteamVR with proxy server and https decryption active.
• Should allow using ALVR with Vive's offline Enterprise SteamVR packages.
• No more worrying about Steam throwing the "app already running" error when it's not running.

Drawbacks:

• If SteamVR isn't the default OpenXR runtime and the given path in settings is wrong it can't find SteamVR. (Could add protocol as a fallback or show a pop-up to let the user know to change their settings).
• No cloud syncing (doesn't really make a difference).

I really wanted an easier way to launch SteamVR this way, it's annoying to have to use a shortcut to the executable and having the automatic restart in ALVR launch Steam. Enabling this greatly improves the experience by removing the wait for SteamVR to launch. If there's stuff you'd like changed just let me know. I'll provide support and updates for the feature must there be bugs or issues with it.

Thank you very much!

[Iemand005]

Here's the difference in sartup speed of SteamVR:

Original:

Recording.2025-08-22.010233.a.mp4

Quick Launch:

Recording.2025-08-22.010411.b.mp4

[zmerp]

Note that we are about to change these parts of the code soon, in #2993. I would say to merge that PR after this one.

[Iemand005]

I renamed the open with dashboard setting to open automatically to make it more recognisable at a glance what the setting does.

Here's a speed comparison of automatic opening:

With Steam:

Recording.2025-08-22.211056.stem.mp4

With quick launch:

Recording.2025-08-22.211106.nostem.mp4

I'd like to note some stuff about the UI:

The width of the text input field seems to be determined by the content length instead of the width of the actual visible control. The text input field should actually try to take up the full width available instead of being a fixed width. It also seems to shift the reset buttons on the right below the control too but not above. It should either only shift the reset button on the row where there isn't enough room, or (what I feel like is more appropriate design) it should shift both the ones above and below.

In cases where the right aligned buttons are really forced to shift outside of the window view, a horizontal scroll bar should be presented so the user can at least reach those buttons, currently it appears as if they're not there at a glance, the user would need to realize this and know they have to resize the window if this happens.

I also think it'd be a nice addition to make it so that if a button is set to automatically set it's width based on the content, set the minimum width to the height of the button and center align the contents of the button. This would make the refresh buttons square instead of the odd slightly rectangle shape they are now, which I feel would look a bit more natural.

There's also chance at overlap:

The toggles and sliders are also not vertically centered.

Combobox is off vertically by two pixels:

The hitboxes of buttons seems to extend 3 pixels outside of the button's graphical area. It'd be a nice but not necessary addition (might require a little more computation) to have the button hitboxes of buttons with rounded corners match the shape of the buttons, so have the button only get highlighted if the cursor's tip is inside the button and not have it select the button if it's in the corner but outside the button.

There are other graphical bugs that are related to this (same things vertically like in the sidebar, the way mouse down and up is handled in combobox, touch vs mouse inputs, scrolling is jumpy, toggles can only be togged with a click and not by dragging the dot from left to right). It doesn't really affect the functionality of the application but having the UI be consistent, robust and respond to user inputs seamlessly and intuitively helps a lot to make people think less of the user interface, gives the app a premium feel and helps people focus on the settings.

I haven't looked at the UI code yet but when I have time I'll probably see if it'd be easy enough for me to make some improvements here.

Let me know if you'd like me to fix the UI a bit and make it a bit more user friendly. I'd love to work on addressing these issues.

[zmerp]

I'm aware of the graphical bugs. We use egui, which is an immediate mode GUI library. egui is the most popular egui library for Rust, but also it moves quite fast, often rewriting the internals completely. Its theming engine is quite weak and pretty buggy, which is what you see as misalignments with the controls (using the default margins it would not produce the same misalignments). Moreover, the weirdness of the layout is caused by egui being an immediate mode gui. Immediate mode means that the library cannot produce the functionality of flexbox, centering, anything that requires knowledge of what will be drawn next (egui actually tries to be smart when using built-in controls but there are pitfalls everywhere).

Despite all of these issues, we decided to go with egui because it will allow to embed the dashboard or part of it inside the client, as it has an easy to integrate WGPU backend.

I'd life if you could give a look at the GUI code. There are definitely quite a few things that can be fixed, and also maybe bugs that can be reported to egui upstream.

[Iemand005]

Awesome!

I'll probably look at the UI code later and I'll do another pull request once I've implemented some proper design tweaks. I've been using the build with the Quick Launch feature now and it works great. I think it's all ready to be integrated into ALVR for the next release.

Thank you very much!

[The-personified-devil]

Please fix the thing I highlighted. It would also be great if you could fix the nitpicks too, because every improvement to code quality is great, but it's also fine if some of those are too much for you to handle.

[Iemand005]

Hey @The-personified-devil,

My apologies for the delay, I wasn't home for a couple days but I got back and applied the requested changes.

I hope it's a bit better, let me know if I missed some things.

Have a nice day!

[zmerp]

Sorry, I forgot to publish my review a few days ago

[Iemand005]

No problem. I fixed it.

[zmerp]

@Iemand005 No other comments from me. Fix the last nit from ThePersonifiedDevil and we can merge

[Iemand005]

My apologies, I had somehow missed that comment. I changed it and simplified the launching logic a bit. I also moved the error out of the utility function as you suggested.

I hope it's better like this, I tested it on Windows, fallback works fine too.

Thank you very much!

[zmerp]

The code in launch_steamvr() was fine as before without rewriting more stuff. You should fix the comments or just revert the code.

[zmerp]

Looks good enough i think

old

[The-personified-devil]

I think this is fine for now, there's some small cleanup things I want to change but I don't want to drag this on even more with confusing review comments, so I'll just make a follow up PR in the next couple of days.