[Suggestion] HUD Support

[Antelux]

When using the mod to create a UI, there doesn't seem to be an easy way to create a HUD, and creating multiple screens isn't possible either. Being able to render fragments during a RenderGuiOverlayEvent would be fantastic.

[BloCamLimb]

I believe an immediate-mode GUI is better suited for HUD use cases. And if we were to add HUD support, we would also need to address mixed layout with other overlay elements. Fragments are clearly not a good fit for that scenario, which makes reusing the existing code within the Minecraft HUD difficult. I'm not particularly interested in going down that path either.

We also have no plans to extend the vanilla HUD's rendering model. Especially after the GUI refactor in 1.21.6, injecting additional logic into the vanilla rendering pipeline has become even more challenging. Historically we had ExtendedGuiGraphics, but it was marked as deprecated in MC 1.21.6.

We would stay focused on building dedicated GUI screens on top of our own rendering pipeline and layout system.

[Etern-34520]

Actually, there is an unstable API to create something like a HUD, but not exactly a HUD.

To achieve that, you can use UIManager.getDecorView() to get a ViewGroup and add a child. You will see that the child will always render, even when a screen is open, and won't interfere with the normal behavior of in-game actions.

However, there are some problems:

Test Environment: Minecraft 1.21.8 Fabric + ModernUI 3.12.0.4

· The "HUD Component" will always render at the top, even with open screens or in the menu.Solution: modify the Z-index of the component

· The "HUD Component" interferes with input events of screens from ModernUI. When the component is added to DecorView, other screens cannot react to any input actions (click, hover, or otherwise). The only way I found to fix it is to press Tab in a view with a focusable component, like a text field, to transfer focus to it. I have tried to transfer the focus automatically through code but failed. I haven't found a way to solve this.

[BloCamLimb]

I know you're referring to a UI (specifically, a Fragment) whose lifecycle is not bound to a Screen. This is indeed part of my plan, which I call the Window Manager and Composition Engine, and it will be implemented in both ModernUI and ModernUI-MC. Simply put, it will allow for multiple UI layers: below the HUD layer, between the HUD and the Screen, above the Screen, or the Screen itself. I do not refer to this as a "HUD," but rather as multiple layers, or more accurately, multiple view trees. Currently, we have only UI layer that tied to a Screen.

I do not refer to this as a "HUD" because, for example, you cannot add a new bar to the vanilla status bars—such as the health bar, via ModernUI API. Therefore, these new layers and the vanilla HUD may "overlap" each other rather than being tiled or integrated. For a true HUD, one should use the API provided by NeoForge. ModernUI will provide your layers as something completely dedicated.

This still requires some time to explore and implement. I am now focusing on the Resources system, which allows developers to define their themes and widget styles at runtime. This system requires no modification to the UI code, you can simply declare a set of styles and switch them with a single line of code, rather than being limited to the default Material 3 theme.