50 minutes ago, maltman said:
want to make a GUI library which inflicts the least amount of mess upon the client codebase as possible.
Where are you drawing the line as "client codebase"? For example ones with their own markup style (e.g. HTML/JS especially with things like angular, XAML, Android XML, etc.) strive to move as much as possible into their declarative syntax and out of the imperative code/language so that the code mostly just handles events, data binding, and bits of dynamic creation/destruction of views, so you don't have a bunch of "new Button(50, 100, 'OK'))" type code.
50 minutes ago, maltman said:
I'm trying to solve the problem of cycling focused elements to the front of render order now. My current hang up is on whether or create a new registry or vector of pointers or if I should just modify the original registry of entities when I want to cycle the elements to the front.
Not really sure without actually seeing your current structure as I never tried using an ECS specifically for GUI. Does one of your components have the ID for the parent and children?
I basically solved this by re-ordering the child references in a "root" UI node so that my child lists are always bottom to top and a tree-iteration can be naturally bottom to top or top to bottom. This doesn't allow me a CSS style "z-index" property however, if I want to add that I would need to track the z-index items separately, and having a separate render/z-order "collection" of all UI elements would certainly work.
A lot of what I did was based on experience writing various complex GUIs in HTML/CSS (with and without frameworks), wxWidgets, Android (find mostly under android.view and android.widget packages), and Java Swing, with some simpler stuff in Unity. Was there any GUI programming you are approaching this from?
As with all 3D rendering, using the depth buffer is also a possibility with the potential benefit of reducing overdraw, but doesn't work with alpha blending, any such elements still need back to front sorting. You also need to consider the need for mouse events to determine the top-most window at any given location, and possibly keyboard navigation to determine the tab-order.