High level architecture overview?

[andrewpros]

Hi.

Is there any more documentation towards developers, like what is the architecture of the project and why it was chosen so? I its seems there is not.

I did tinker with the project in vs so i see its 3 projects, main code, UI app and capture dll, the only dev docs i have found are in the source code comments which is super helpful and to be honest fine. Only wish there was more about the architecture, i get the dll, but why 2 apps etc.

Sometimes there are things connected to how openvr works like the overlays, like i discovered the laser pointer is in fact an overlay and things like that, would be nice at least have more comments in the source regarding this things.

Also is it only me or the laser pointer should be always visible but is not?

Anyway, why im asking, cuz i wanted to make some important QoL changes and some big ones too, like better UI, but im not sure there is more dev docs that could help.

[elvissteinjr]

There's indeed not much for developers to go off of. I blame this on Desktop+ being more of a personal project of mine than a community one. Not that outside contributions aren't welcome overall, but my focus has been to just get stuff done and committed as I see fit. There weren't many devs to please here over the past few years either way.

As for the architecture of the app... it's mostly a consequence how it grew to be what it is today. It's definitely not an example of great design, but it does run and I'd rather deliver more functionality to end-users than throw it out entirely. Some restructuring is on my wishlist after the new UI is done... but that by itself is already holding me up. Smaller cleanup is already taking place for some parts where they got mostly replaced.

The main binary started off as the DXGI Desktop Duplication Sample with OpenVR overlay output bolted on, later got support for multiple overlays somewhat taped on top. OutputManager grew to be a main class handling most things... well a lot of them are related to each other at least. Currently the main loop hinges on Desktop Duplication delivering frame updates or them timing out. This is fine in most cases, but uncoupling the capture code entirely similar to the newer methods would be desirable in the future. Especially after Valve added a way to frame sync with the SteamVR runtime for overlays (this previously wasn't the case). There's not much abstraction going on and a few things deal with SteamVR quirks here and there (and some trickery on undocumented behavior to be fair). It is very much dependent on how things work with the runtime.

The UI portion being its own process was just thought as a way to have strict separation of the capture portion and config interface (also making the UI optional). As it stands right now, the UI process does quite a bit more than just setting a few values as initially intended. IPC via window messages also seems clunky at times, though it does work out for now. It's not wrong that these two binaries may as well just be one with separate threads. Merging them might be an idea, but not something I want to tackle right now.

WinRT stuff is separated for compiler/SDK support, as well as not to pull in all WinRT stuff into the main binary. As time goes on these are likely lesser concerns, but it forced a decent degree of separation for the capture code at least.

Browser is a separate binary as it kinda has to be or else it'll be painful to work with. Probably never want that to have elevated access either. It's an optional component since I'm not a fan the Chromium bloat and it outweighs the main application by a lot for something not everyone needs. It might not be considered massive by today's standards, when almost every application ships their own Chromium copy anyways, but doesn't mean I need to follow the trend.

Guess this is more of a historical justification than a true overview. Many things were made up on the spot and are what they are for now. I hope they still make sense to some degree.

Also is it only me or the laser pointer should be always visible but is not?

The laser pointer overlays are only for the custom laser pointer used by Desktop+ (in the newui branch, but I assume you're looking at that already). It doesn't interact with any overlays by other applications and can't receive controller input while the SteamVR dashboard is up (the SteamVR system pointer is used then). Having it only be visible sometimes is intentional. Well, you also don't want lasers constantly coming out of the hand controllers during gameplay either.

i wanted to make some important QoL changes and some big ones too, like better UI

I'm curious about those changes but as a bit of a heads up, I'll probably be wary of bigger changes while I'm still remaking the UI myself with larger pieces moving about here and there. Not that I can or should stop you from anything. At the very least I wouldn't exactly be looking to throw out the newui branch work for something entirely different again, though. Of course only a concern if you were looking to upstream your stuff in the first place.

[andrewpros]

Thank u for all that information.

All in all i really do think the code and architecture is good anyway, its very fine, was just looking for more specifics.

Im not really into the browser things, not sure why ppl wanted it as u can just run your browser in an overlay.

I just want to make things more centred towards usability and and ease of use, but is see it more like standalone multi media/monitor centre hub than a software to display some windows during gameplay.

Cuz truth is, its quite universal software, u can use it during gameplay but u also dont need to, as i mentioned u can use it as some kind of multi centre hub or even for work in vr to just display multiple window setups.

So it would be nice to have more options toward that kind of setup, i mean when steamvr dashboard is hidden and u just work with the overlays.

Like the laser pointer, what i would want it to have

• be visible between overlays not just when pointing the overlays, yes, could be bad for gameplay, but helpful for standalone use
• more options, make it point only without the ray, ability to change color, point size maybe even more things, or better yet dynamic
• dynamic options, based on current usage, like make the pointer point more visible when on overlay, the same with the laser ray option, maybe make the laser ray a gradient, more visible the closer to overlay surface

Things like that, what i want to make. And then on top of that more finely tuned details.

Like my initial tests showed that there is an additional delay for overlay action bar to disappear when laser is leaving the overlay, but not when entering, so i found that, learnt why it is that, there were comments, but i wanted to have control and give control to users how fast it shows/hides, so that delay needed to go, so i changed that.

But there are others, like i want the action bar to be movable or at least configurable to any side of the overlay, left, center, right, top, center, bottom, or better yet, dynamic, based on the vector a pointer is moving from, also for the action bar to show even before the pointer is on the overlay to make those nice smooth enter/leave animations, everything fully configurable.

The last thing im still researching as right now it seems that the laser pointer/overlay works the way that the pointer needs to be on the overlay to get a hover event and only then the action bar can be shown, but the overlay size is only based on the texture which is the size of the actual capture window, so for now the code works in a way its impossible to get a distance based show/hide of the action bar before entering/after leaving the overlay cuz thats the bounds of it.

Other things are the UI ease of use and usability.

Like, to drag an overlay i need to click the drag toggle, then drag the overlay, then disable drag again, but i would want it to be much simpler, why not just drag when holding the drag handle and thats it, no need to toggle, no need to click drag/overlay/drag.

The other UI parts are also too small, like exit buttons and other handles and overall the UI elements of settings/config windows, action bars, the overlay context menu in dashboard etc. i did even make a steam post about it and some other things some time ago.

Not sure how other see this, but it should be at least configurable, i use it myself and no way its the right size, many times its just too small and it makes it very annoying having to constantly deal with precise aiming.

I will basically say the same thing as i wrote in the steam post, VR UI should be more like mobile UIs, u dont want it to be too small, it needs to be easy to aim with the pointer and click it, drag it, check it., etc. not that it is unusable, its just in a spot where it takes needless effort to point and use things, so this is also a thing i want to make better.

Thats my goals and thats why i will need to do this as a fork anyway, to much changes to discuss.

[elvissteinjr]

be visible between overlays not just when pointing the overlays, yes, could be bad for gameplay, but helpful for standalone use

This should be the case when toggling laser pointer visibility via an input binding. The other things make sense. For now the laser pointer was modeled to look as almost the same as the system laser pointer.

Configurability in general is nice, but there needs to be a balance somewhere. Many times I troubleshoot issues with someone, I see that the "Open ReadMe" action button is still in its default spot. Maybe it's convenient there, but the main intention was that the user discovers how to get rid of it after using it once. So a lot of the times the settings aren't changed by the majority of users. Too many options can also get overwhelming, while hiding most of them makes them hard to be discovered. None of this applies when you code for your own personal preferences of course.

About scaling the UI: You can change the sizing of the floating windows already. The window buttons themselves should just scale up if you increase the image dimensions. Haven't tested what happens to the layout if you do so, however. I'm not a fan of mobile UIs myself to be honest. Texture size is limited as well... okay it's not literally limited, but I've certainly noticed the texture copy over to SteamVR putting strain on lower end GPUs the higher you go in resolution. Texture space is less than 4k right now, but a 125% scale on everything would shoot past it for example.

If none of this matters to you then I believe should be able to get away with scaling the ImGui style values and font size, the icon files and adjusting the texture space values. For desktop mode it already scales with the screen DPI (no higher res icons, however).

Or you could replace the current system with a more dynamic one. Just know there are trade-offs with that, like unavoidable flickering on SteamVR's end from not being able to adjust texture size and texture coordinates together atomically (suppose you could fade-out all UI overlays briefly to mask it... eh).

So yeah, doesn't sound exactly like something that could get merged back right away indeed and my priorities are somewhere else right now. Nevertheless I'll keep an eye open and try to answer any further questions if you have them.

[andrewpros]

Yeah, i get it, but its vr, still kinda new thing, if ppl want to use it they need to learn a little, there is already a advanced settings switch in the UI, but to be honest u are right that things need to be clear, easy to find and use, then maybe the issue is not in having those options, but in the way to show them, maybe i could make it more clear.

Also im no a fan to sacrificing options just cuz some users cant handle it.

And i wasn't talking about scaling UI per se, but more about the relations, u can read the windows content no issue, but then u want to close a window with x (setting window) and it is so small relative to everything else.

Not sure why u are not a fan of more mobile UI, i mean not mobile as is, but the principles behind it, to make things big enough to use them easily where it is needed and as an example i provided, there is no way a bigger exit button is less convenient than a small one.

Well i probably need to tinker more with it and make some graphs how it works.