Formspec/HUD Replacement

[v-rob]

They say good things come to those who wait. Or maybe v-rob's just a perfectionist or lazy or something. You decide. But in any case, I'm tenacious, so here's the current code for the fabled Formspec Replacement ^TM. This is the real deal, the actual base that everything's going to be built off of.

Will resolve #6527, if you couldn't guess. But it's also the HUD replacement.

Before anyone asks (and I know someone will), there is no frontend API, and there won't be for some time. I care about the client code and the JSON backend right now. If you want a frontend, write it yourself for now.

Screenshots?

Sure, here's a lame screenshot of round-mode tiling of textures with a partially transparent fill color of red via the Design class, set as the background of a centered Elem with a size of half the screen:

Documentation?

Nope. I haven't taken the time yet, but it's high on the TODO list so people can actually test this garbagestuff out if they want to. I wanted to get this PR out here today, but I just spent the entire day debugging a particularly nasty piece of undefined behaviour with only std::cout statements because Visual Studio is no help, and so I didn't feel like writing documentation.

The same rationale applies to a test program and better screenshots.

To do

Lots and lots. Each of these is approximately a commit of its own except for the later ones where everything's still fuzzy.

• JSON serializer and deserializer
• Irrlicht texture wrapper so Irrlicht texture management, drawing, clipping, and stuff are safely abstracted away.
• Basic UI: Manager manages a list of Envs, Env manages a hierarchy of Elems, Elems can draw basic stuff to the screen. Send the UI from the server via a JSON string through minetest.show_formspec() with a formname of __builtin:__ui_update.
• Layout with axis layout system.
• Make documentation for the JSON serialization structure and layout system.
• Make new GUI drawing interact well with existing GUI instead of drawing right on top--this includes interfacing properly with z-indexing for the HUD.
• Create event handling infrastructure. Create Button class, sans text, to be the first non-Elem element. Send event handling to server via minetest.register_on_player_receive_fields() with a formname of __builtin:__ui_event.
• Implement state-based styling. Create Style element or something in Env to allow styling based on universal, element type, ID, class, state. Child/parent/other hierarchy selectors may be good extensions, but are by no means necessary at this stage. Remove inline styles from JSON; equivalent is style by ID (since all elements have IDs). Implement equivalent of formspec prepends for styles in Manager.
• Add a virtual element system, e.g. for buttons in scrollbars and for scrollbars in scroll containers. Allow styling them with things like CSS pseudo-selectors. Implement both scrollbars and scroll containers.
• Implement text with HarfBuzz and ICU. Implement static text fields and text in buttons.
• Create all the other elements. There's probably a few steps inside here :)
• Maybe improve styling further wishlist. Child/parent/other hierarchy selectors would be useful. Animations would be awesome.
• Make a proper Lua API at some point during this process instead of just having a JSON backend.
• Probably should make a proper network process for sending the UI instead of hijacking existing formspec APIs. But for now, ehh, who cares?

How to test

minetest.show_formspec(player, "__builtin:__ui_update", "backend JSON data"). Yes, this is clunky for now, get over it. I appropriated the formspec API temporarily because it was easy to do that.

[v-rob]

Oops, the blog post linked here, and it's been over a month since any activity's been seen. That's embarrassing :/ Never fear, however. I work in sprints, and I finished this WIP PR at the very end of a Minetest sprint. I'm currently sprinting on another project, but it's very likely that it'll peter out and I'll transition back to this.

[AuroraBorealish]

How's this going? Any parts I could help with?

[v-rob]

It's undergone some pretty hefty changes since I last pushed anything (replaced JSON with binary serialization, added styling support, and I have a buggy and incomplete Lua API in the works that I'm busy refactoring/rewriting, among other changes). The PR isn't dead; I'm just quiet about my work since I like to get a solid chunk done before pushing. The TODO list at the top is also horribly out of date.

It's difficult to coordinate direct help from anyone else at this stage since everything is too incomplete to get any separable work out. If anything, finalizing SDL2 as the primary/only backend for IrrlichtMt is the only prerequisite that I want to get in before I do too much with events, ideally. I haven't looked too deeply into that recently.

[v-rob]

Continued in #14263