Open shiftyscales opened 3 years ago
This is not necessarily desirable, particularly when working with LogiX, because destroying a LogiX node you initially focused on would disable the mode. I'll see if there's a way to handle this on case by case basis instead, but it might be tricky to deal with.
I can't speak for other use cases, but so far I've found I've started off my Logix by focusing on the node browser, and building things out from there.
I never actually have changed the focused UI element after getting started yet- although I can see how this might be different for cases where the user is editing existing Logix.
It doesn't seem like it would be terribly inconvenient to have to refocus the camera onto the UI if they destroyed it though, and doing so would mean the behavior is consistent so a user could learn to avoid destroying their currently focused UI if they don't wish to continue using it.
Having the granularity would probably be the more flexible option, though.
That works well only when you use that workflow, but we can't make that assumption - I don't use that myself and that would result in the UI camera randomly unfocusing in such cases.
Is your tweak request related to a problem? Please describe.
While using the UI camera, and closing the UI that is currently focused, it would feel nicer to be automatically returned to their previous camera.
Describe what would you like tweaked
After a UI is destroyed (inspector, node browser, etc.), the user is returned to their previous camera.
Describe alternatives you've considered
An on-screen prompt/button to exit the UI camera/switch camera modes.
Additional context
A newer user that isn't entirely familiar with the binds or how to escape the UI camera might be confused after they close the UI but find their camera locked.