GUI Library TODO

[TheGlitch76]

This is a list of the Fabric API modules that need to be ported to QSL for the gui library. Feel free to make a PR for any module in this list, though consider discussing your port in the Toolchain Discord first.

• [x] Screen API
• [ ] ScreenHandler API
• [x] (#59)

The new module should have the same core features as the Fabric equivalent, but refactors, reorganizations, or expansions in scope are allowed.

Please leave a comment if this list is incomplete or missing a Fabric API module that was added past when the original QSL RFC was written.

If you are interested in becoming a maintainer for this library, please contact the QSL Core team on the Toolchain Discord!

[i509VCB]

I guess I have a bit of wisdom to add to this topic regarding the hud (which is probably gui by category).

The biggest issue I recall around this discussion was tracking what is essentially a tree of elements to draw.

What I'd like to propose is an abstraction around a scene graph:

A scene graph is optimal for the hud imo for a few reasons:

• A scene graph represents drawable elements with scene nodes
• Each scene node inherits the render state of the parent and can apply transforms to their children.
• Scene graphs make ordering draw operations something you can do before rendering, effectively forming a linear queue of elements to draw.

There is some existing precedent in Minecraft for something like this with the MatrixStack. The MatrixStack effectively acts like a scene graph for transforms.

[xanderstuff]

The biggest issue I recall around this discussion was tracking what is essentially a tree of elements to draw.

Something similar exists to what you are describing, if I'm understanding that correctly. Both @burgerguy's HudTweaks and my UltimateHUD mods add an abstraction layer to the hud, organizing things into a tree of Elements/Widgets, where the state (position and size) of parents affect their children's position (according to how the child wants to be positioned relative to its parent).