[Resolved][Beta 2.9.1] Desktop overlay extra controls shown for every dashboard overlay

[elvissteinjr]

(also applies to 2.9.2 of course)

I'll phrase this as a bug report as there's zero mention of it in the changelogs and having those buttons on every dashboard overlay doesn't necessarily make sense a lot of the time (especially the multi-task view button).

As the developer of Desktop+, this change breaks a few things in my overlay application. Granted those things are hacky and relying on unspecified behavior. Whatever, I'll fix them up if needed.

So my real question here is if all of this is even intentional.
As said, some of the buttons don't make sense, and isn't there VROverlayFlags_EnableControlBar to control this sort of UI?
If it is, I guess I'd like to ask for a way to opt out of having that control bar for my dashboard overlay?
Thanks.

As an aside, talking about overlay flags... VROverlayFlags_MultiCursor is great but still doesn't seem to have a way to trigger haptics on the secondary cursor's controller.

[DOTCOM]

every time i connect it just says host connection is lost and my vr (quest 2) is plugged in which this is confusing me so much and it says waiting for wireless vr to connect its stupid i don't know what it means and im sure as hell trying to not to do wireless is there a fix or do i have to pay even more money for another connection cable

[J Bot]

Thanks for flagging this. The change to enable overlay controls by default was intentional, but we don't want to regress apps such as yours either! Let us look into options and get back to you.

[elvissteinjr]

Thank you for the response (and I suppose thanks to dotcom seemingly getting lost here and bumping the thread).

If the control bar stays, then so be it. Docking every dashboard overlay or sending it to the theater screen is neat (but the app switcher button everywhere is is still debatable imo).

I essentially just wish for a way to opt out of having this control bar, but I'll explain why, just in case:
In Desktop+, the dashboard overlay is just a blank dummy to serve to get a tab and have a reference position. This is to side-step restrictions of dashboard overlay transforms and display multiple overlays while the tab is selected.
This makes the control bar useless for it. But even if I were to make the dummy be a proper overlay, I'd end up with the control bar for this overlay only, while my application may display multiple that all warrant having the same level of functionality.

Another thing is that I already provide the functionality the control bar offers on my own and display a set of buttons below the overlays as well. This also includes a custom keyboard implementation and theater screen integration, so everything is covered.

The other breakage I mentioned was related to the dummy-relative positioning, but I sorted that out on my end (in beta branch for now if you end up checking the app out, but I don't see the need).
That's me relying on implementation details of where dashboard overlays end up displayed, so it's also on me to keep correct, of course.

At the end, the bar is just a mild annoyance and source of user confusion for my application, as most buttons won't do the right thing here.
Looking forward to hearing back from you. Thanks again.

[J Bot]

In an upcoming steamvr beta release we will expose a new overlay flag,
VROverlayFlags_MinimalControlBar = 1 << 26

Setting this on your dashboard overlay should allow you get the old visual style back.

You can go ahead and start setting this for now in your code -- it should not cause any issues in the interim even on the normal version of steamvr.

[elvissteinjr]

Will do. Thank you!
Since I can't see its effect yet, does that position the dashboard overlay in the old spot, same as currently stable, or does it keep the newer one, just without the controls visible? "Minimal" suggests there's still something, I guess?

Either is fine, I just have some things that are using the transform as a reference as mentioned before.
Then again, as this hasn't hit the stable SteamVR branch yet I'm not in a rush and can wait for the beta build to check myself.

1 << 26 used to be VROverlayFlags_Reserved, but it hasn't ever been something else in the public headers so I suppose nobody's been using it.

[J Bot]

This flag as currently implemented omits the entire control bar, and draws the dashboard overlay in a lower Y position. I am not confident it's in the exact location as the internal hierarchy is a bit different, but the intention is the same.

We named the flag "minimal" as we'd like to reserve the right to show some minimal elements even in this mode (although we're not currently doing so). Long term it would be preferable to give you an official way do place your overlays, to allow for better support.

[elvissteinjr]

I can confirm the flag does what it's supposed to in the newest SteamVR beta build.
Position of the dashboard overlay is also not meaningfully different from before on stable, so I just went with removing my workaround offsets on that end.

Thanks again. Interest in triggering haptics on the secondary laser pointer device for VROverlayFlags_MultiCursor is still there *wink*... but I suppose this is not the topic for that.