Add SteamVR offline launch feature#2994
Conversation
|
Here's the difference in sartup speed of SteamVR: Original: Recording.2025-08-22.010233.a.mp4Quick Launch: Recording.2025-08-22.010411.b.mp4 |
|
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.mp4With quick launch: Recording.2025-08-22.211106.nostem.mp4I'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. |
|
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. |
|
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! |
|
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
changed the title
zmerp
left a comment
zmerp
left a comment
There was a problem hiding this comment.
Sorry, I forgot to publish my review a few days ago
|
No problem. I fixed it. |
|
@Iemand005 No other comments from me. Fix the last nit from ThePersonifiedDevil and we can merge |
|
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! |
The-personified-devil
left a comment
The-personified-devil
left a comment
There was a problem hiding this comment.
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.
The-personified-devil
removed this pull request from the merge queue due to a manual request
Resolves a single conflict in alvr/xtask/src/build.rs by taking upstream's libvpl.dll copy step (needed for the new Intel VPL encoder, #be9396b3) and dropping our dead-commented vrlink_bin_dir block. Our resource-tree copy logic auto-merged into the next block. Restores command::copy_recursive in alvr/xtask/src/command.rs and adds the corresponding `use crate::command;` import in build.rs — upstream removed copy_recursive from command.rs but our resource-copy step still calls it. All other touched files auto-merged cleanly. Notable upstream additions that affect or complement our fork: - alvr-org#2871 PSVR2 Sense controller emulation establishes the {alvr_server} resource token convention upstream — same pattern we adopted for Pico. - alvr-org#2994 SteamVR offline launch adds settings.extra.steamvr_launcher .use_steamvr_path, removing the need for our planned launcher fix. - alvr-org#3140 Pico 4 headset emulation (HeadsetEmulationMode::Pico4) coexists with our ControllersEmulationMode::Pico4 work. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 participants
Added a toggle to choose to directly start SteamVR instead of using the steam protocol.
Benefits:
Drawbacks:
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!