Sooo tired of all these languages. Rust, Jai, Odin, Zig, C3,... Just give me struct, enum, union, basic types, if, for, while, switch and static arrays and I am happy. Everyone is trying to reinvent the world with their list of favorite features and perceived wisdom of what is right or wrong.

Also awe inspiring what our players are building in game

Absolutely hear you every time I implement it is bug prone and somewhat difficult to write the implementation (state-machine code, with all variables having to live in a context struct to be reentrant).

Always tried to think about that user comfort is more important than author comfort for APIs

Depends somewhat on the API and the problem to solve and if there are other resource requirements as well but personally I really like coroutine style APIs: gist.github.com/vurtun/192ca... (the zip example here is better than the json one).

Seeing all the great stuff you post Mikko about 2D SDF really calls me to implement more SDF outside circle as well :D.

Seems more like a fact at this point more than just a opinion :). Even read this sentiment from a younger dev influenced by Casey and Jon. He tweeted "The sign of a good programmer is having strong opinions and voices them as such". So equate being a good programmer with being an asshole.

Older devs (game adjacent now) looking down on new gen as not hardcore enough are full of shit.

My generation does old time consoles prog as a hobby. We would love to work on old consoles with time schedules of 6 month instead of 6+ years. Gamedev today feels like feeding dragons (hardware,content)

This is what it looked like (left). Lots of different fonts, styles, row heights. Everything is a mess and hurts to look at for longer stretches of time. Meanwhile we use same row height everywhere (right). Same row height lets eyes get used to it and focus on the job and less on parsing noise.

Only exception are list elements with 3D previews or Images that need more visual space. Even then these we limit down to a multiple of our default row height to create visual cohesion. This constraint is the distinct reason why our editor looks very clean and easy on the eyes

As for different row heights. After investigating the old lumberyard editor and working on our editor we found out that it is very important not change row height. Especially for UI that is looked at for long stretches of time. All style and height changes are attention stealer and strain over time.

Wrote my version with cutting here: gist.github.com/vurtun/2561f... to test it. Since all top level layouting is always header,content,footer I can do it intuitively at this point. I perfer to do the layouting first and then widgets. Sub-layouts always in function or scope to prevent messing up.

So far I haven't found a one fits all solution that fulfills both and is nice to use for either case. Either a lot of configuration has to happen to the higher abstracted API bloating everything beyond the more verbose API or a lot of defaulting is required that in the end becomes bloated as well.

The magic and ergonomics was always a bit of a balancing act for me. For quick UI for example debugging I prefer higher abstractions like the final example in my gist that combines layouting and widgets while for production level ui I always want full control and often very custom widgets

Oh also if not by function I try to make use of scopes to make it easier to notice bugs like that. Big advantage of layouting is that visually at least it is easy to see that something is wrong and scopes/functions helped me to find the source a bit faster

Btw I am always open to discuss or talk about anything related to ui and share my experience and have so in the past with a few people on discord. I am not very good at writing :)

It depends a little bit. I tried to split up my code so that every "big" split is basically its own widget and therefore function. So never try to layout everything at once unless I have to for a single row for example. So the number of rects to jungle is small. Still happend but fast to see and fix

I would be really interested in your specific example of complex layouting that is awkward to do with the rect cut API. Ironically Tau became spartan over time based on my experience of seeing more "complex" widgets breaking down under additional requirements in our editor.

What I personally also prefer is having an explicit rectangle parameter for each widget. So generating layout position and size is not coupled together with any hidden layout or ui system. Means it can come from anywhere

In my experience so far the value of per-calculating desired sizes is mostly interesting for text and at least for me holistically looking at complex UIs not really used outside of that. I think in our entire editor I see no real place were it is realistically necessary.