First party support for context menu bedazzling

[Earthmark]

Is your feature request related to a problem? Please describe.

Users often have custom backdrops to the context menu, and the current strategy to inject those backdrops is the same hunt-using-find-slot options as was used in classical injection. This may be needlessly brittle, and context menus may be a viable thing to make easily to customizeable.

Relevant issues

Current workarounds to implement #2433 may be more stable depending on the approach taken.

Describe the solution you'd like

Having a template menu may be a possible thing, like how the streaming camera is templated, the context menu may be similarly templated.

This directly addresses the user want to provide a custom context menu, the same way they want to provide a custom name plate or desktop-ball-cam. However I'm guessing given the re-creation and positional requirements of the menu, that may not be viable.

Describe alternatives you've considered

Leaving as is, this is more brittle, but is viable. This may lead to another context menu break like what happened with the desktop camera ball being introduced.

One alternative may be to add a field to the ContextMenuItemSource that points to the arc that was generated, that way users could get the context menu slot through that means. This approach would help current implementations of #2433, as they could get direct access to the arc slot without the search method.

Additional context

The context menu jazzing up is often not a canvas element, it's often virtual parented from inside the user and is a form of 3D geometry. Sometimes it's a full model with effects, sometimes stacked images that spin, it's quite customized.

Currently I've seen this implemented as a copy-into-menu-on-open style logix circuit, and as a virtual parent with the target slot getting assigned on menu open.

[Frooxius]

I'm not sure when we'd prioritize something like this directly, because there are things we might want to do with the context menu in the future that won't be compatible with this and until we're sure on the direction I don't want to constrain the design on our end too much.

One thing we could do is make it easy to find the context menu root, with the caveat that the structure and elements beyond that can change, but that could still keep some behaviors brittle if you depend on the structure too much. It'd be relatively quick add on our end without promising too many guarantees (other than giving you the root of it reliably).

[AshtonSparx]

I personally, and I know several people feel the same way, very strongly dislike the "context menu bedazzling" everyone is doing. Making it play noises when they open & close their menu, attaching pictures, items, tools, some people even turned it into a tool shelf to store items in their context menus, light sources, particle systems, ect. It wouldn't be As bad if they at least made the sound local or not exist at all. But it's still has it's flaws.

Many times I've seen when someone spawns in or equips their avatar. Their "context menu bedazzle" is a million scale large. Like, world consuming till they open it up. I think a First Party solution would just make it more rampant and annoy users, like me, even further.

[Frooxius]

That's actually something we could standardize with first party solution. We can add elements that you can locally disable. Since it would be official, unless someone overrides that system with their own, all of them would conform to that functionality.

[3x1t-5tyl3]

So would that just allow you to basically work with UIX in your context menu ( #2433 For example for radial sliders and similar)? Or am I misunderstanding it a bit here where it would just give you the slot for it for you to inject stuff yourself? 🤔

[ProbablePrime]

Radial Sliders would be a different feature that we're considering separately afaik.

[AshtonSparx]

I actually raised a GH request #2569 for things like the radial visual stuff for context menus :) first party solutions for that would be awesome and possibly make it easier for other things to be implemented as well

[Earthmark]

I think #2569 and #2433 may be duplicates then, they are both asking for an analog kind of control.

Either way, I think providing a way to reliably access the context menu would be viable for this use case, the goal of this request is to make current approaches less fragile. This may end up getting used for radial injections in that it can reliably find the context menu, but I think that's a side effect, and is just as brittle to internal menu structure changes.

I think there scale issue is a side effect here, where if not implemented correctly the context menu decoration may be x1000 normal size due to the required canvas scale. It does indicate an implementation issue with the decoration, but it's caused by the canvas needing a very small scale. Perhaps the slot provided to users could have a user-unit scale instead of 1/1000 scale (or whatever it is)? Then if people use the requested feature for decorations their decoration can be at unit scale and they can convert to unit if they move to the reliable component.

I think I'll open a separate GitHub request about canvas scales, it's a very common pain point when working with canvases.