[nickmqb]

Do UIs need to be trees?

How do things change if we were to use a list instead? What becomes easier/harder?

Layout calculations might become slightly more expensive, though it seems that that may be acceptable since most time is spent rendering; and perhaps there are other ways to accelerate these calculations if needed.

The fact that most UIs are happy to provide a single linear tab order (and not something more involved that allows users to navigate the tree structure) makes me think that there might be something there.

[adamnemecek]

How would you represent a ui as a list?

[nickmqb]

A list of widgets, with each widget having a x, y, width and height.

[chrismorgan]

It’s normal for UIs to need some sort of nesting, e.g. menus, tabs (including things like tab panels and ribbon UIs), flexible split panes. It’s possible to do all of these without a tree, but you’ll be doing what nesting does, just at a far more painful level. Switch from tab A to tab B → hide all the A widgets, show all the B widgets. Adjust the split position → recalculate the position, width and height of every element that’s “within” it. Scroll a scrollable panel → adjust the y position of every element that’s “within” it, and also probably refresh the clip masks that every widget must now have since scrolling makes partial occlusion possible.

[gpm]

What is a widget?

Is a text box with a reply button a widget? What about just a text box? What about just a button?

Assuming all three, it sounds like you have one widget composed of two other widgets, which naturally ends up creating tree structures.

[stephc_int13]

Do you think about code as a tree?

It is, in some ways, but this is not the best model to reason about code, IMHO.

[gpm]

I do when I'm trying to operate on it with other code (e.g. compile it - equivalently render the gui). Typically you parse it into a syntax tree.

[stephc_int13]

If you had to reason about your code as a tree when writing it, I think it would quickly be cumbersome. Remember that we're talking about the API here, not the internals of the implementation.

[alvarlagerlof]

I dare you to make a website using only css position: absolute; Make it work on different screen sizes. Do independent scrolling. It'll be hell very quickly. Nesting is used in all somewhat complicated layouts.

[nyanpasu64]

Win32/MFC dialog layouts are based off absolute positioning of all widgets, with a few concessions to resizability (like the ability to select whether a widget moves down or stay still when a window gets taller). This is the reason why many dialogs, like Run, or Windows Explorer file properties, cannot be resized.

Any hierarchy (group boxes holding widgets) is purely visual, and the rectangle doesn't "own" its child widgets in a programmatic sense.

Text widgets have a fixed size. If your font gets wider (from DPI scaling or translations), text can become cut off or overflow onto the next line and disappear.

[gitgud]

This demonstrates the main advantage of a tree structure, which is relativity.

You can say that all nodes on this leaf of the tree are contained within that node... It's an elegant way to describe a UI in my opinion.

[dsego]

How about with css grid?

[pier25]

Sure, but you're going to need to have dependencies among those widgets in one way or another.

Eg: You want to move a button and you need to move its text and background shape. How do you keep track that these two elements are grouped together?