Itâs not clear to me exactly what feature this is requesting, or what your pain point is. Could you provide an example of what âfiltering functionalityâ would entail here, and what is âvery frustrating and complexâ? Iâm assuming that having these folder-like frames nested very deep, and navigating into them (both in the explorer and via scripts) is what you are finding cumbersome. If thatâs the case, well, the TLDR is that filtering has proven itself to not be viable solution to this problem.
In short, the container-based hierarchy is pretty standard for UI layout, and for good reasons, and this is unlikely to change.
The Long Explanation
Robloxâs Frames are just containers, equivalent to div blocks in HTML/CSS documents. If youâve ever browsed the web with your browserâs developer tools open, youâll have noticed that many of layers of containers is commonplace. I donât know exactly what âfilteringâ would look like in this context, but suppose, for example, UIPageLayout had a blacklist, so you could exempt âBackâ from its effects. OK, that solves one small organization problem or needing an extra container, but replaces it with a new and much hairier problem: how to resolve conflicts between children of a container who have mutually-exclusive constraints applied to them. This problem is precisely why document object models have lots of containers, because grouping and explicitly arranging things has proven to be the simplest way to achieve a specific, desired result. This is a problem that many have given a lot of thought to; everyone involved in the decades of development of markup languages for the web, for example.
So my first question to you would be: is there another solution you can think of that would address your pain points? For example, a different way of visualizing the structure of the UI that is easier to edit? Just because a data structure solves a problem well does not mean the interface and tools we have for working with it cannot be improved upon through feature requests!
As for scripting, a very complex and deeply-nested UI is not something a programmer should attempt to handle with equally deep references to things. Beyond maybe 2-3 levels deep, direct paths to elements should be abandoned as a practical solution. In other words, no one should have code that looks like this:
local frameBkgd = player.PlayerGui.Shop.Inventory.Frame.Frame.Hats.BlueHats.FuzzyBlueHats.Frame.Frame.HowDeepDoesThisEvenGo.Frame2.Products.Image.OMGAnotherFrame.Frame.BkgdImageFinally
So how is this solved then?
When you get into developing large, sophisticated UIs, new methods are required to keep things sane and scalable. It will quickly become apparent how incredibly painful it is to maintain deep, explicit paths to things within a large GUI, and to keep it all functional while UI designers are iterating on the design. This is not because theyâve used too many containers, or the organizational structure is flawed, itâs because this approach to coding for it is fragile and not suitable. Traversing a complex GUIâs tree and acquiring references to the things you need programmatic control of is a viable approach. Agree on naming conventions with your designer to identify elements you need references to, or use the new CollectionService. With a few simple rules, you can write flexible code that is tolerant of things like inserting new layers of containers, or changing the number of a certain type of element.
I understand what youâre suggesting. It would not be an Adornee exactly, but a similar A-applies-to-B relationship set up via reference. But I donât believe that solves the OPâs problem, it does not change the number of containers required. If anything, it makes the whole UI more difficult to assess at a glance, since the constraints could be stored anywhere. Even though you can do this with things like welds, people generally parent welds to one of the things they are connecting (Part0 or Part1), or to a container that holds them both, because the alternative invites a loss of sanity.
