Dynamic depth management

[ssoher]

Currently the controls are drawn in order they appear in code as most IM gui's do. Their drawing order doesn't change for the lifetime of the program. This forces elements to be mostly static. Adding 2 moving windows, the last window dragged/moved/resized doesn't get drawn on top of another window unless user implements own solution where windows/controls with their content are put in some sort of a data structure which is sorted based on user interaction dynamically.

I think this is something raygui should solve generally. Or at least provide an optional parameter to override the "depth" of the controls so it becomes trivial to change the draw order of some controls when they are interacted with.

This not only solves the given moving floating windows example, currently if one wants to add a dropdown box as the first control, with other controls under it, one has to call the dropdown box code after the rest of the controls in the window so when it's opened the dropdown doesn't get rendered behind the other controls.

[colesnicov]

Hello. That seems like a big problem. I haven't tried it that deeply yet, but I'm already scared of it.

I know about Dear ImGui.

Things like this were resolved there 7 years ago and I remember that it was resolved then. Back then it was like that, overlapping of windows, rendering of an element inappropriately, or the fact that the last window was not rendered...

At the time, it concerned, I think, the rendering lists..

O'Cornut is a dude..

[raysan5]

Hello. That seems like a big problem. I haven't tried it that deeply yet, but I'm already scared of it.

@colesnicov It has never been a problem for me in the last 6 years, and I released a dozen tools using raygui.

@ssoher I'm afraid trying to address this issue could imply a considerable redesing of raygui and raylib library. As mentioned, it was never been a big issue for me. Do you have some proposed solution to address it in a simple way?

[ssoher]

Do you have some proposed solution to address it in a simple way?

Sadly, no. An array of structs to represent gui draw calls, inside the struct a generic void pointer to a draw function along with a number of variables to pass as arguments to that function, a depth value and the control type from an enum to cast the function pointer back to the actual gui function call it represents, and a for loop that calls these functions in the array every frame would work I guess. Then the array can be sorted based on the depth variable inside each struct. I can't think of a "good" way. And in any case, as you said it would take some significant change on the library design side I guess.

[colesnicov]

@colesnicov It has never been a problem for me in the last 6 years, and I released a dozen tools using raygui.

Course, these are things that can be lived with. Personally, I use Dear ImGui because it's been many years.. But RayGui appeals to me because it's actually such a companion for RayLib..

I like RayGui, but Dear ImGui has been around for many years, has a strong base and provides a lot of options. And it can be combined with RayLib. But RayGui is good. Good work.