Hi,
I always seen GUI in an hierarchy of parent-child way like this:

This is what you will see in absolutely most of the GUI like Qt or so on.
But is it still a modern way to write a good GUI?

Alundra said:
But is it still a modern way to write a good GUI?

What's that for a question? It implies ‘modern’ and ‘good’ would be somehow the same thing. :D
I guess your question is ‘are tree views an intuitive way to visualize hierarchical relationships?’
Ofc. that's a yes, because hierarchies form trees, so those two are the same thing.

What they can't show so well are graphs (All trees are graphs, but not every graph forms a tree).
In this case something like a node view with connections became a very common GUI element, thus it's maybe ‘modern’ because we did not see this often decades ago, and many GUI libs still provide little functionality to help implementation.
Example would be typical material editors.

What i mean is: Look at how your data structures relate to each other, then you know if to use list view / tree view / node graphs, etc.

You right, I was not enough precise.
GUI is in development in the world since very long time and we used to do a classical parent-child tree like Qt.
But now there is this immediate GUI style and surely a lot of things that I am not aware in the GUI world.
One link explaining a lot is this: https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/Slate/Architecture/
My

(Adding a new message because it looks like there is a bug that cutted the previous message and avoid to edit it anymore)

My question is more about what would be the best strategy nowadays to write a modern UI that can be efficiently used in a full 3D engine editor and in game.
For example IMGUI is very good for debug but I don't think it would work very good in a full 3D engine editor.
I think this is what Unreal link is trying to explain too.

Oh, then i got you totally wrong. Sorry for the trolling tone.

Personaly i'm fine with using ImGui for editor and tools. It has all features i needed til yet. And so far it did not cause me issues like a need to search for bugs.
Ofc. it renders with the scene, so if your framerate is low, GUI becomes slow too. Would not happen with using OS gui elements, but that's not portable and cumbersome.

The main potential downside of immediate GUI seems code clutter to me. Because it's so easy to use, we may tend to have GUI cluttered across the whole code base. What starts out as ‘debug code’ becomes ‘good enough UI’ and sticks there. But this can be avoided or fixed later ofc.
I rarely tried to make it looking good, or placing elements precisely for certain layouts. But if needed, this can be done as well.
Sometimes it feels a bit hacky, code style does not feel modern either, but i don't see a reason to add another dependency or make GUI myself. I did so decades ago, and it's quite some work. I'm pretty happy i no longer need to maintain this.

Alundra said:
(Adding a new message because it looks like there is a bug that cutted the previous message and avoid to edit it anymore)

@jbadams

This bug was there one or two years ago, then fixed, now it's back.
If you paste a link you can still type, but after clicking Post the text below the link is cut and gone.
A work around is to paste links only after you are done with the typing. But everybody looses at least one post until figuring this out.

I thought about this very intense as well when we decided how our SDK should handle UI in our graphical tools and the game engine itself. We ended up with our current plan:

I studied HTML rendering for a while so the idea was to break UI down into independent nodes that come from a designer, HTML or XAML parsers and have them WPF like build the render tree using reactive programming and a fully data driven processing pipeline. That pipeline is responsible to process nodes by applying custom layout and rendering actors per node, into the layout tree which is then used to determine the render tree.

Exchangeable actors allow to modify how nodes are layouting and rendered and one could also add totally new nodes without the need to write an own user control. An example that benefits from this practice is adding the engine interface to an editor UI.

Another benefit is life editing of UI in a running application, so you don't have to stop and recompile UI changes but could be able to open a tree or code view window and change everything on the fly

This seems like a recurring problem, recently I was reading about avalonia , a wpf extension for c# , I want to give it a try and create a gui editor with c++ dll , don't know how much is feasible and how much time consuming it is, I have used also imgui and I find it riddled with rendering bugs to the point I am in the mood of : ok, its temporary , will wiat for better , but the better never comes. I think its time to give c++ a good gui interface or it won't last enough to see the next decade in my opinion.

I think part of the confusion is the data representation versus the visual style.

The data is usually a simple hierarchy, a tree where each element passes commands up the tree until it is handled. Manipulating an element of the tree also effects every element beyond it, like closing a box hides all the elements it contains, moving it also moves the content, etc. While small details evolve, the overall pattern is unchanged since the 1960s or so.

The visual display and the API calls to efficiently render it can vary based on the display system. It can take work to minimize draw calls, minimize system calls, buffer data to avoid flicker and to avoid processing, and so on. Sometimes software composition to make the image is less costly than making hardware calls, sometimes not. This seems to be in constant flux to match this year's hardware, and for the latest visual fashions.

Beside UI design and implementation, there is also the question if games need a GUI at all, which is rarely discussed.
To me it mostly feels like crutches, and should be avoided and replaced by the native interface games offer, which is the in game controls and interactions.

IMO the worst case is the popular ARPG genre. That's usually full of confusing GUI pages, e.g. to show character properties, inventory, crafting, endless skill tree, map, etc.
All those are abstractions, a bad concept which does not integrate with the main games simulation model and visualization. More or less the GUI functionality becomes a second game breaking and competing the main experience.

This is what happens to me, e.g. if playing Skyrim, Cyberpunk etc.:
At first i experience a 3D world from TP / FP perspective. The world is visually immersive, contains physics simulation to enable interaction, i can move freely and aim at enemies to shoot at them, etc. The standard things which is nice.
Then i open some crate or loot some corpse. A GUI element shows up, interrupting the gameplay and immersion.
I need to study the GUI options, trial and error, to find out what hidden functionality is exposed. Mostly it's about things the developers failed to handle in their main simulation model. I find out my character has unique skill points, e.g. to increase effectiveness of magic weapons, or even increasing flirting skills with woman (and men ofc., it's 2022 :D ). It boils down to number games about stats and probabilities. Something pen and paper or board games have to do, but computer games could implement this differently, by integrating such features in to the main simulation model.

To me, once you need GUIs to implement your action game, you're almost always admitting failure on simulation design, or you try to do things computer games just can't do yet.
It does not work, so i try to ignore GUI functionality. I do not even try to increase my stats or acquiring skills because this leads to a need to operate on GUI pages, which is just boring and annoying to learn.
I rarely finish such games. I stop playing even before i'm too weak due to missing skills. Such abstraction crutches are one of the main reasons modern games are rarely any fun to me and feel more like work.

Off topic again, but it has to be said ;D