Add Api for screen layering.

[mysticdrew]

This PR is a direct port of my utility mod.
I was encouraged to PR this into fabric.

This api allows screens to be layered on top of each other, so you can have more than one screen displayed at time.

https://github.com/mysticdrew/FabricScreenLayers

[Devan-Kerman]

The api surface should be changed

mod a: adds health bar overlay
mod b: adds armor bar overlay
mod a: I no longer need the health bar overlay
mod a: popLayer() -> pop's armor bar overlay instead

same concept applies for if REI or something wanted to use the API. Additionally it's just kinda annoying to use a stack-based system to manage sub-screens

[mysticdrew]

The api surface should be changed

mod a: adds health bar overlay mod b: adds armor bar overlay mod a: I no longer need the health bar overlay mod a: popLayer() -> pop's armor bar overlay instead

same concept applies for if REI or something wanted to use the API. Additionally it's just kinda annoying to use a stack-based system to manage sub-screens

These are not overlays, these are screens.
Only the top layer or all layers can be removed. Middle layers are not intended to be removed.
Mods don't really have a need to put screens on top of another mod's screen. That sounds confusing anyways.

[Devan-Kerman]

ok so it's just for one mod, but managing screens as a stack is still annoying. it would be much easier to deal with a map instead of having to pop-pop-pop-push-push-push-push to swap out a screen in the middle. I don't see why there has to be an arbitrary restriction on how screen layers can be added or removed.

[mysticdrew]

ok so it's just for one mod, but managing screens as a stack is still annoying. it would be much easier to deal with a map instead of having to pop-pop-pop-push-push-push-push to swap out a screen in the middle. I don't see why there has to be an arbitrary restriction on how screen layers can be added or removed.

This is a simple way to render a screen on top of another screen. You cannot interact with the screens below, mouse clicks and key presses are not passed through. Only the top layer gets the clicks and presses.

Call the pop on your screen's close method, it removes the screen from the stack and the one below it is rendered and can be interacted with.

This is not a random collections of screens, this is a LIFO stack of screens. I will not even attempt to manage a LIFO map of screens, that sounds brittle.

[Patbox]

Since it's not intended for mods to be compatible, wouldn't extending Screen class to add layered rendering support be better? As I'm sure it should be possible to do that (while not being too hard), which would require less mixins and made state local instead of global.

[apple502j]

I would like to see where your mod is currently being used. Screenshots?

The vanilla design for a screen is to take the parent in the constructor and switch to the parent when closed. Unless some overlay is needed, this is probably fine. No need to make it more complex.

[mysticdrew]

I would like to see where your mod is currently being used. Screenshots?

@apple502j I use it in JourneyMap for the right click context menu on the Fullscreen Map. Then, I do not have to worry about managing any clicks on the map while the menu is up.

I can get screenshots later after work.

[XFactHD]

The vanilla design for a screen is to take the parent in the constructor and switch to the parent when closed. Unless some overlay is needed, this is probably fine. No need to make it more complex.

My use case for this is a modal window which keeps the original screen in the background for context and whose closing must not re-init the original screen. Vanilla Minecraft has no use case where the original screen should be rendered behind the "stacked" one.

[Patbox]

These two seem like can be solved by just calling render/init methods of parent screen in the current one, without need for handling stacking on global state

[mysticdrew]

Since it's not intended for mods to be compatible, wouldn't extending Screen class to add layered rendering support be better? As I'm sure it should be possible to do that (while not being too hard), which would require less mixins and made state local instead of global.

These two seem like can be solved by just calling render/init methods of parent screen in the current one, without need for handling stacking on global state

This then requires the developer to handle passing all input calls to the screen, one layer, sure not much of an issue. Many layers it can get messy.

This solution, which is similar to how Forge does it, Minecraft takes care of the screen management of the top most screen, which includes rendering and inputs.

While sure, there are multiple ways to handle screen layering. This is by far the simplest for someone wanting to use the feature.

[haykam821]

In today's snapshot, Mojang introduced a popup screen that renders a parent screen behind it. I think we should stick to vanilla conventions and avoid introducing unnecessary complexity to how screen rendering works.

[Patbox]

This implementation breaks once some other mod sets the screen (as it clears when someone else changes screen) and then tries to restore it vanilla way. This is why implementing it fully within screen would be better as it avoids this issue

[apple502j]

Note: class_8816 in 23w40a implements a stackable popup screen. Not a drop-in replacement, but that provides a good API.

[mysticdrew]

Interesting, this is good I guess.
Not quite a drop in replacement, but close.
Main difference is my implementation any screen no matter what can be stacked. This implementation, only the custom screen can do it.

Seems this is not needed/wanted for fabric. I will close it.